Похоже, что пакет заброшен , так как в течение 4 лет обновлений нет (! ).
Попытка починить устаревший пакет, как правило, не стоит усилий. В этом случае вашими лучшими вариантами являются
найти альтернативный пакет для интеграции с postgreSQL
найти ветвь пакета , что решило проблемы совместимости
самостоятельно разветвите пакет и обновите версии NPM или преобразуйте пакет для работы без жесткого подключения к конкретной версии NPM.
Ресурсы для достижения этой цели:
https://guide.meteor.com/writing-atmosphere-packages.html#peer-npm-dependencies [ 112]
https://github.com/tmeasday/check-npm-versions
Общие чтения:
https://guide.meteor.com/atmosphere-vs-npm.html
https://guide.meteor.com/writing-atmosphere-packages.html [ 115]
Что делать, если ничего из этого не относится к вам, потому что
Сначала вы обязательно должны открыть проблему в репозитории и описать свою проблему как максимально подробно:
Обратите внимание, что приведенные выше пункты также применимы к Stackoverflow в качестве критерия для «хорошего вопроса». Если владелец репо не отвечает через неделю, вы можете привлечь его внимание, используя @nameOfOwner
в комментариях.
Дополнительные ресурсы можно найти здесь:
https://stackoverflow.com/help/how-to-ask
https: // stackoverflow.com/help/mcve
Делая все эти усилия, вы повышаете вероятность того, что некоторые члены сообщества обнаружат вашу ошибку (потому что меньше усилий воспроизвести, когда ошибка хорошо документирована) и решите проблему или раскройте репо.
Последний, но не менее важный золотой способ - решить проблему, прочитать о пакете и его работе, проверить код и попытаться его исправить. Напишите несколько тестов, задокументируйте исправление и, наконец, откройте запрос на извлечение, чтобы поделиться улучшениями со всеми остальными пользователями пакета.
Я <3 файлы тега, но что ведущий разработчик JSTL курит трещину, если они действительно сказали это. Вы не МОЖЕТЕ переписать все теги библиотеки тегов, поскольку файл тега отмечает по одной очень важной причине: файлы тега не могут сделать:
возвратите EVAL_BODY_INCLUDE;
Другими словами, файлы тега только имеют три опции для своего содержания тела:
пустой: никакое внутреннее содержание, т.е. <someTag/>
без сценария: никакое внутреннее содержание JSP, т.е. <someTag> <p> привет мировой </p> </someTag> не в порядке, но не <someTag> <p> <% = helloWorld.toString () %> </p> </someTag>
tagdependent: у Вас может быть внутреннее содержание JSP, но оно не будет обработано как таковое; вместо этого необходимо анализировать/представлять его однако, Вы считаете целесообразным
Но со старыми тегами библиотеки тега style, Вы можете иметь: <содержание тела> JSP </body-content> (в tld файле) и затем "возвращает EVAL_BODY_INCLUDE"; от Вашего "doStartTag". Если Вы сделаете это, то все Ваши директивы JSP будут проанализированы так же, как если бы они были нормальной частью Вашей страницы, и Ваш тег просто переносит их с соответствующим содержанием.
Лично, мое эмпирическое правило: используйте файлы тега каждый раз, когда Вы можете, т.е. каждый раз, когда Вам не нужны директивы JSP для работы в теге, потому что они - инструмент для очистки миллиона раз, легче для непрограммиста работать с, не требуйте tld (хорошо, если Вы сохраняете их в отдельном пространстве имен от Ваших тегов библиотеки тегов).
Но если Вы хотите содержание JSP в своем теге, Ваша единственная опция является тегами библиотеки тегов. Хотелось бы надеяться, когда-нибудь, люди JSP выпустят способ сделать директиву JSP, обрабатывающую в теге файла тега, и затем мы действительно можем отказаться от старых основанных на классах тегов, но до тех пор не пытайтесь сделать все теги с файлами тега, поскольку Вы будете быстро уменьшены до создания пользовательских тегов для каждой последней части логики (так как это - единственный способ сделать логику, не используя директивы JSP).
Проблемы, разрабатывающие пользовательские теги
Традиционные пользовательские теги требуют навыков программирования Java.
Всех кроме самых простых пользовательских тегов не легко записать.
Цель JSP, в отличие от сервлетов, состоит в том, чтобы использовать язык разметки для управления расположением со встроенным динамическим контентом.
Необходимость написать сложный код Java в пользовательских тегах, которые фокусируются на языке разметки, идет назад.
Мы могли бы хотеть использовать язык выражения JSP или другие пользовательские теги при реализации нового пользовательского тега.
Файлы тега решения JSP 2.0
Как файлы тега отличаются?
Записанное использование синтаксис JSP.
Определенный или .tag или суффиксом .tagx.
Предназначенный для обеспечения пользовательской простоты разработчиков тега разработки без потери функциональности.