Условно изграждане на 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 за генериране на множество буркани с различни/филтрирани класове? или http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)

Въпросът ми е как мога да направя това вместо това? Ако изградя допълнителен модул с моя специфичен за теста код, който да включа в моето внедряване условно на профил, имам проблема, че моят ejb-jar.xml трябва да се намира в META-INF директорията на точно този jar файл, тъй като моят допълнителен "test" модул ще се съдържа в различен буркан, следователно ejb-jar.xml няма да бъде приложен към ejbs в моя оригинален буркан.

Някакви предложения, как бих могъл да разреша този проблем (създаване на специално тестово ухо с модифицирани дескриптори за разполагане и допълнителни класове) по maven начин?

Съветите и прозренията са високо оценени :-)


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

Отговори (2)


arrow_upward
0
arrow_downward

Най-доброто решение е не да създавате отделни EAR за тест/продукция и т.н. от едно и също . но ако наистина искате да правите това, трябва да създадете два отделни модула за уши:

 +-- 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