#java #maven #jboss7.x
#java #maven #jboss7.x
Вопрос:
Мне нужно сгенерировать module.xml
файл для JBoss7 для проекта maven, в котором много зависимостей от jar. Какой самый простой способ сделать это? Файл выглядит следующим образом:
<module xmlns="urn:jboss:module:1.0" name="ats.platform">
<resources>
<resource-root path="dom4j-1.6.1.jar"/>
<resource-root path="jdom-1.0.jar"/>
...
</resources>
</module>
так что <resource-root>
элемент должен быть создан для каждой jar-зависимости проекта.
Или, может быть, я делаю что-то не так? Как правильно создать модуль JBoss7 из проекта maven?
Комментарии:
1. Я создал программу, которая удалит ненужные (неиспользуемые) банки из пути к классу проекта. Вы ищете такую вещь?
2. Нет, мне нужно создать jboss-модуль из существующего проекта maven. Но интересно, что вы подразумеваете под «удалить» и «нежелательный»? Насколько я понимаю, вы могли бы просто управлять
<dependencies>
в файле pom. Что именно делает программа?3. Обычно мы добавляли все банки ur, а затем удаляли один за другим и проверяли зависимости. Но вместо этого я создал программу, которая будет считывать все банки, которые вы изначально сопоставили. Затем я найду те, которые не имеют зависимости от текущего проекта или каких-либо связанных классов в текущем проекте. И я предоставляю выходные данные желаемых и нежелательных jar-файлов и одного jar, которые необходимы для работы вашего проекта.
4. Обычно я поддерживаю актуальность зависимостей, поэтому требуется все перечисленное. Более того, некоторые зависимости могут быть неявными, например, реализация API (xerces или ws) или jdbc-драйверы.
Ответ №1:
Я действительно не знаю о JBoss и есть ли другой способ сделать это, но вы можете сделать это довольно просто с помощью GMaven:
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<configuration>
<source>
def sw = new StringWriter()
def xml = new groovy.xml.MarkupBuilder(sw)
xml.module(xmlns:'urn:jboss:module:1.0', name:'ats.platform') {
resources {
project.runtimeClasspathElements.each {
def path = it.find(".*?([\w\.-]*\.jar)") { it[1] }
!path?:'resource-root'(path:path)
}
}
}
println sw
</source>
</configuration>
</plugin>
Следует отметить несколько моментов:
- Этот скрипт выводит XML в стандартный вывод, но вы, очевидно, можете очень легко записать его в файл или что-то еще.
- Они
runtimeClasspathElements
содержат абсолютные пути к jar, поэтому я анализирую его с помощью регулярного выражения. Вы можете настроить регулярное выражение так, чтобы оно включало больше пути или просто добавляло строку, если вам нужно больше, чем просто имя файла jar.
Я опубликовал рабочий пример на github (это просто POM), где я привязал приведенную выше конфигурацию плагина к фазе инициализации сборки. Если у вас есть git, вы можете клонировать и запускать его самостоятельно с помощью:
git clone git://github.com/zzantozz/testbed tmp
cd tmp
mvn -q initialize -pl stackoverflow/7755255-gmaven-to-build-xml-from-classpath
В пример проекта я добавил jdom 1.0 и dom4j 1.6.1 в качестве зависимостей, и вот результат, который он создал:
<module xmlns='urn:jboss:module:1.0' name='ats.platform'>
<resources>
<resource-root path='jdom-1.0.jar' />
<resource-root path='dom4j-1.6.1.jar' />
<resource-root path='xml-apis-1.0.b2.jar' />
<resource-root path='aspectjrt-1.6.11.jar' />
</resources>
</module>
Примечание: я не специалист по groovy, поэтому может быть более простой способ сделать это, но вы можете видеть, насколько это просто.
Комментарии:
1. Где я могу найти документацию для gmaven? Google показывает некоторые устаревшие ссылки … Например, где описание таких вещей, как «runtimeClasspathElements»?
2. Ссылки Google не устарели. Прочитайте страницу и перейдите по ссылкам. У GMaven есть wiki в Codehaus с множеством основных элементов. К сожалению, документация немного легкая, но с Groovy обычно довольно легко ориентироваться.
3. Я не могу найти никакой информации для материала. Например
runtimeClasspathElements
, здесь не описано. Или я смотрю в неправильном направлении? docs.codehaus.org /… ничего не дает. Я не сомневаюсь, что это должен быть более правильный способ извлечения имен файлов и типов упаковки артефактов вместо использования магии регулярных выражений. Также неясно, в какой области они находятся — compile, runtime, test и т. Д.4. Да, неправильное направление.
project
является MavenProject — частью Maven API и не имеет ничего общего с GMaven. Все, что вам нужно знать о Maven, находится на его странице проекта . Javadoc находится в типичном месте для проектов Maven. Также есть сообщение в блоге, в котором упоминается об этом . Кроме того, я думал, что runtime ClasspathElements очень четко описывает его область действия.5. О, и вы всегда можете провести самоанализ во время выполнения:
project.getMetaPropertyValues().each { println it.name ": " it.value }
, используя расширение Groovy Object . Подробнее об этом в этом блоге , в пакете groovy.inspect и в Groovy Reflection .
Ответ №2:
Вы могли бы попробовать smartics-jboss-modules-maven-plugin
Он обеспечивает довольно мощный контроль зависимостей:
- исключения и включения (также с подстановочными знаками) из deps проекта,
- определение deps для других модулей JBoss,
- обработка переходных зависимостей
- и многое другое
С соответствующим дескриптором сгенерированный модуль готов к копированию «как есть» в JBoss 7.
Пример jboss-modules/foo.bar.foo-module.xml:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="foo.bar.foo-module">
<match>
<includes>
<include>
<groupId>foo.*</groupId>
</include>
<include>
<groupId>org.*</groupId>
</include>
</includes>
<excludes>
<exclude>org.slf4j.slf4j-api</exclude>
</excludes>
</match>
<apply-to-module>
<dependencies>
<module name="org.slf4j" />
</dependencies>
</apply-to-module>
</module>
Также установите для excludeDependencyManagementDependenciesInPomProject значение true в конфигурации плагина smartic, чтобы избежать включения 50 МБ deps 🙂
Комментарии:
1. Хотя эта ссылка может ответить на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы только для ссылок могут стать недействительными, если связанная страница изменится.
2. Спасибо за отзыв, Маркус.
Ответ №3:
Это можно легко решить за несколько шагов.
-
запустите
mvn dependency:list -DoutputFile=dep.list -DoutputAbsoluteArtifactFilename=true
в своей оболочкевы получите файл, подобный этому:
The following files have been resolved: ch.qos.logback:logback-classic:jar:0.9.30:test:C:Dokumente und Einstellungenmichael-o.m2repositorychqoslogbacklogback-classic0.9.30logback-classic-0.9.30.jar ch.qos.logback:logback-core:jar:0.9.30:test:C:Dokumente und Einstellungenmichael-o.m2repositorychqoslogbacklogback-core0.9.30logback-core-0.9.30.jar classworlds:classworlds:jar:1.1-alpha-2:compile:C:Dokumente und Einstellungenmichael-o.m2repositoryclassworldsclassworlds1.1-alpha-2classworlds-1.1-alpha-2.jar
Важная информация в файле с отступом в 4 пробела.
-
Теперь извлеките важную информацию и не забудьте ограничить область компиляции и выполнения.
- разделите столбцы с
cut -d ':' -f <colNum>
помощью и получите последний столбец. - Получите имя файла после последней (обратной) косой черты.
- Теперь создайте XML-файл с информацией.
Каждый может быть упакован в хороший сценарий оболочки.
Смотрите maven-dependency-plugin
Для справки.
Быстрая команда выглядит следующим образом: cat dep.list | grep -E ':(compile|runtime):' | cut -d ':' -f 7 | sed -e 's////g' | xargs -I {} basename '{}' | xargs -I {} echo "<resource-root path="{}" />"
Выходные данные содержат имена файлов jar:
<resource-root path="classworlds-1.1-alpha-2.jar" />
<resource-root path="jsr305-1.3.9.jar" />
<resource-root path="guava-10.0.1.jar" />
<resource-root path="commons-codec-1.3.jar" />
<resource-root path="commons-io-2.0.1.jar" />
<resource-root path="commons-lang-2.6.jar" />
<resource-root path="junit-4.9.jar" />
Теперь оберните XML-заголовком и нижним колонтитулом, и все готово!
Комментарии:
1. Это зависит от платформы. В Windows нет grep, sed и т. Д. Я думаю, что это должно быть возможно с помощью maven-antrun-plugin, но я не очень хорошо его знаю (я ожидаю, что стандартный ant недостаточно мощный для этой задачи). В крайнем случае - я мог бы создать для него новый плагин maven.
2. Да, это так. Конечно, это можно было бы сделать с помощью antrun, но гораздо больше работы, чем моя единственная строка unix cmd. Очевидно, что вы не можете избежать кодирования.
Ответ №4:
Хотя этот вопрос довольно старый и уже имеет правильный ответ, я хотел бы упомянуть другую альтернативу.
Поскольку мы начали с модулей JBoss, мы написали небольшой плагин для Maven, который генерирует папки модулей с module.xmlsоснове XML-дескрипторов. Плагин называется smartics-jboss-modules-maven-plugin, и вы найдете дополнительную информацию о нем в блоге проекта.
Мы только начали работать с ним, но он уже выполняет процесс синхронизации между POM и module.xml (плюс структура каталогов) для наших проектов очень проста.
Недостатком этого подхода является то, что вам нужно изучить дополнительный XML-дескриптор и настроить дополнительный плагин Maven. Поэтому для небольших проектов вам может быть лучше следовать решениям ответов выше.
Если вы хотите попробовать, плагин лицензирован по лицензии Apache License 2.0.