Как вы генерируете зависимости модулей в MANIFEST.MF для JBoss AS 7 с помощью maven?

В JBoss AS 7 веб-приложение, которое зависит от библиотек, содержащихся в AS, должно объявлять эти зависимости в META-INF / MANIFEST.MF следующим образом:

Dependencies: <package-name>

Пример:

Dependencies: org.slf4j

(Это сопоставимо с Import-Package: для OSGi.) Дополнительную информацию можно найти в статьях о переход со старых версий, class loading и неявные зависимости модулей для развертываний

Проект построен на Maven. Все зависимости, включенные в AS, объявляются с областью видимости "provided".

Теперь вопрос

Есть ли простой способ автоматически создать этот список зависимостей с помощью Maven?

Должны быть включены только зависимости с объявленной областью видимости 'provided', потому что все остальные уже включены в WAR.


dependencies java maven jboss jboss7.x
person migu    schedule 14.07.2011    source источник

Ответы (2)


arrow_upward
27
arrow_downward

Эти зависимости объявляются именами, с которыми артефакты maven не имеют сопоставлений. Вероятно, вы могли бы синхронизировать groupId с именами модулей jboss, но я не уверен, что это хорошая идея. И я до сих пор не могу придумать никакого автоматизированного решения.

Но есть место, где вы можете управлять конфигурацией вручную, как описано в одном из источников, которые вы указали в своем вопросе:

   <build>
       ...
       <plugins>
         <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-war-plugin</artifactId>
           <configuration>
              <archive>
                 <manifestEntries>
                    <Dependencies>org.slf4j</Dependencies>
                 </manifestEntries>  
              </archive>
           </configuration>
         </plugin>   
       </plugins>
    </build>

Я надеюсь, что кто-нибудь придумает плагин, который сделает его менее громоздким.

person Mike Minicki    schedule 16.07.2011
comment
org.slf4j - это идентификатор группы артефакта, поэтому Maven это уже знает. Однако этот идентификатор группы используется несколькими артефактами. Как JBoss узнает, какой jar имеется в виду? - person migu; 16.07.2011
comment
@migu - Загляните в папку modules / org / slf4j / main в корневом каталоге jboss (поскольку она импортируется этой зависимостью org.slf4j). И особенно посмотрите на module.xml, который действует как его дескриптор. Как видите, это совпадение, что группа maven и этот модуль используют одно и то же имя. - person Mike Minicki; 17.07.2011
comment
Именно то, что я искал! - person Jared Knipp; 02.02.2012
comment
Похоже, это единственное доступное на данный момент решение. Обратной стороной новой модульной системы JBoss является то, что мы должны поддерживать два перекрывающихся набора зависимостей в POM и искать модули, которые мы можем использовать вручную. - person migu; 09.05.2012
comment
Вот что я понял: положительным моментом должно быть разделение модулей на отдельные области загрузчика классов. Это позволяет использовать разные версии jar в одной AS. - person migu; 04.06.2013
comment
Maven может определить область, в которой упоминается информация о том, каким будет имя модуля JBoss. Таким образом, разработчики могли ссылаться на эту область, чтобы найти столь необходимую информацию. - person gkephorus; 27.03.2016

arrow_upward
1
arrow_downward

Этот код автоматически добавляет все ваши зависимости компиляции в ваш MANIFEST.MF

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-war-plugin</artifactId>
   <version>2.4</version>
   <configuration>
      <archive>
         <manifest>
            <addClasspath>true</addClasspath>
         </manifest>
      </archive>
   </configuration>
</plugin>

подробнее здесь: http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html.

person Jérome Pieret    schedule 08.11.2013
comment
Как уже указывал Михал Миницки, это просто совпадение, что группы maven и некоторые модули имеют одинаковое имя. Следовательно, добавление пути к классам не поможет, потому что JBoss AS ожидает имена модулей. - person migu; 05.12.2013