2016-11-24 4 views
5

Мы создаем ухо, которое будет работать в Websphere, где предоставляется j2ee.jar.Должны ли банки иметь «предоставленные» зависимости?

Теперь у нас есть ситуация, когда ejb (назовите его ejb.jar) зависит от другой банки (назовите ее util.jar), которая зависит от j2ee.jar.

Если знак j2ee.jar в pom util.jar как «предоставлен», ejb.jar не будет создан, потому что предоставленный не является транзитивным. Если мы помечаем его как «компиляцию», это может стать компиляцией зависимости уха, если мы не перепишем область действия.

Каков наилучший подход? Должен ли util.jar предоставлять зависимости, даже если это просто скромная банка? Или, если банки имеют только компиляцию зависимостей?

+0

Предполагая, что вы используете IDE на основе ecipse, добавили ли вы [добавлено] (http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.wst.server.ui.doc.user%2Ftopics%2Ftwinstprf.html) среда выполнения, совместимая с WebSphere или J2EE? – Lightbeard

+0

Я вижу, что вы строите с maven, я думаю, [это] (https://www.ibm.com/support/knowledgecenter/SS8PJ7_9.0.0/com.ibm.etools.maven.doc/topics/localrepo.html) является эквивалентный способ добавления связанных фреймов времени выполнения. – Lightbeard

+0

@Lightbeard. Спасибо за ваши комментарии, но это не о создании в среде IDE, а также о том, как получать зависимости в локальном репозитории.Речь идет исключительно о том, как построить помы полезным и правильным способом, если «обеспечиваемые» зависимости используются в транзитивных баночках. –

ответ

2

JAR могут иметь предоставленные зависимости ... но пользователь, имеющий зависимость от него, должен убедиться, что эта зависимость действительно будет предоставлена ​​во время выполнения. Поскольку предоставленные зависимости не являются транзитивными, они также должны убедиться, что они не зависят от него для компиляции; но если они это сделают, наилучшей практикой было бы объявить ее явно с помощью области компиляции (или предоставленной), а не полагаться на некоторую форму транзитивности (посмотрите на цель плагина зависимостей, который, например, перечислены в таблице analyze используемые, но необъявленные, зависимости).

  • Предоставленные зависимости в JAR могут быть полезны при создании исполняемых JAR. Рассмотрим построение uber-jar (JAR с классами, в которые включены все его зависимости): вы можете сказать, что определенная зависимость не должна заканчиваться в uber-jar, поскольку запуск этого контейнера обеспечит это во время выполнения.
  • Кроме того, JAR может нуждаться в зависимости от компиляции своего кода, но на самом деле его не нужно запускать; в качестве примера рассмотрим плагины Maven, которые объявляют maven-plugin-annotations as a provided dependency, потому что им нужны только аннотации, которые нужно построить.
  • Конечная точка: есть JAR, у которых есть хорошая идея, в каком контексте они будут использоваться: Spring WebMVC, например, определенно зависит от API сервлета для компиляции, но во время выполнения он знает, что он собирается использоваться в контексте Java EE и что Servlet API будет предоставлен сервером Java EE.

Как правило, помимо случаев, описанных выше, вы, вероятно, не хотите иметь JAR-зависимостей внутри JAR-проекта: он должен быть до клиента, чтобы решить, зависят ли некоторые зависимости от времени компиляции ваши будут предоставлены для их конкретного случая, и пусть клиент переопределит область действия. Как писатель библиотеки, вы действительно не знаете, как будет использоваться ваша библиотека.

В вашем конкретном случае, так как на самом деле нужно ejb.jarj2ee.jar компилировать, лучше всего было бы заявить, что зависимость с компиляцией, или даже с помощью прилагаемого объема в вашем случае, независимо от того, что сфера util.jar установил для j2ee.jar. (Я буду замечать, что для JAR-утилиты есть зависимость от того, что, по-видимому, является JAR из классов веб-приложений Java EE.)