Условно построить файл EAR с maven

У меня проблемы с поиском решения для создания разных версий моего EAR (с плагином maven-ear-plugin).

Я бы хотел иметь возможность создавать EAR для производства или EAR для тестов, где тестовый EAR имеет разные дескрипторы развертывания ejb-jar.xml, а также некоторые дополнительные классы из папок src / test.

Единственный способ, который я нашел до сих пор, - это ввести профиль «blubb», в котором я переопределяю конфигурацию jar-plugin, чтобы включить ejb-jar.xml из src / test / resources, а также некоторые файлы java, и добавить настраиваемый суффикс к моему идентификатору артефакта (или установите классификатор). Затем введите тот же профиль в моем развертывании pom, где я полагаюсь на артефакты, обладающие суффиксом, для создания модифицированного EAR.

Я читал в разных источниках, что ЗЛО (то есть не способ Maven) создавать разные банки одного и того же проекта в зависимости от профилей. (например, Лучшие практики Maven для создания нескольких jar-файлов с разными / отфильтрованными классами? или http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-почему-вы-shouldnt/)

Итак, мой вопрос: как я могу это сделать? Если я создам дополнительный модуль с моим тестовым кодом для включения в мое развертывание условно в профиле, у меня возникнет проблема, заключающаяся в том, что мой ejb-jar.xml должен находиться в каталоге META-INF именно этого файла jar, поскольку мои дополнительные Модуль "test" будет содержаться в другом jar-файле, поэтому файл ejb-jar.xml не будет применяться к ejbs в моем исходном jar-файле.

Любые предложения, как я могу решить эту проблему (создание специального тестового уха с измененными дескрипторами развертывания и дополнительными классами) способом maven?

Мы высоко ценим советы и идеи :-)


maven jakarta-ee ear
person pete83    schedule 09.07.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Лучшее решение - не создавать отдельные EAR для test / prod и т. Д. Из одного и того же. но если вам действительно нравится это делать, вам следует создать два отдельных модуля уха:

 +-- root (pom.xml)
      +--- mod-ejb (pom.xml)
      +--- mod-xxx (pom.xml) 
      +--- mod-ear (pom.xml)
      +--- mot-it-ear (pom.xml)

Это означает наличие двух модулей EAR, которые могут иметь разные дескрипторы и т. Д.

person khmarbaise    schedule 10.07.2013
comment
Но предположим, что у меня есть 200 модулей, каждый из которых устанавливается в моем локальном репо, затем я выполняю свой pom развертывания, где я собираю все 200 зависимостей и кладу их себе на ухо. Я не уверен, как мне настроить содержимое отдельных проектов на этом этапе, если, например, 50 из 200 проектов нуждаются в файле ejb-jar.xml в их META-INF. Мне пришлось бы сначала построить их по-другому, с другим идентификатором артефакта, не так ли? Таким образом, все 200 проектов должны были быть разными, и я не знаю, как этого добиться, не могу дублировать каждый модуль ... - person pete83; 10.07.2013
comment
Причина появления двух ушей в том, что необходимо смоделировать определенные компоненты для определенного типа теста на ухо ... - person pete83; 10.07.2013

arrow_upward
0
arrow_downward

Я нашел способ добиться того, чего хотел, используя maven-dependency-plugin.

Основная проблема заключалась в том, что код нельзя было дублировать, и, тем не менее, тот же модуль должен быть построен с дополнительным / заменяемым контентом по запросу.

Я сделал это следующим образом: создал второй модуль и объявил модуль, который я хотел изменить, как единственную зависимость. Затем в цикле сборки я добавил maven-dependency-plugin с целью «unpack-dependencies» и выбрал для распаковки исходной зависимости в папку target / classes во время «prepare-package».

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

В целом это все еще все, но красиво, на мой взгляд, у Maven было свое время, но теперь пришло время для лучшего инструмента сборки ;-)

Кстати, если кто-нибудь знает более элегантное решение, я все еще открыт ... Моя проблема часто заключалась в том, что я ни при каких обстоятельствах не хотел дублировать свою конфигурацию или даже свой код. И кажется, что Maven действительно усложняет задачу ...

person pete83    schedule 10.08.2013