Jaki jest przypadek użycia, zapytasz? Załóżmy, że korzystam z narzędzia, dla którego jedynym słusznym rozszerzeniem jest xyz. W jaki sposób najmniejszym wysiłkiem utworzyć plik o zadanym rozszerzeniu nie łamiąc zasad rządzących Maven2 i wciąż móc korzystać z pozostałych wtyczek?
Jedyne, co przyszło mi do głowy to skorzystanie z wtyczki - maven-antrun-plugin. Wykonanie polecenia mvn package działa, ale mvn install już nie. Czy są inne sposoby rozwiązania tej kwestii? Skorzystanie z dedykowanej wtyczki? Dedykowany packaging z własną konfiguracją wtyczek?
<properties>
<nazwaPlikuWynikowego>${project.build.directory}/${artifactId}-${version}</nazwaPlikuWynikowego>
<rozszerzenie>xyz</rozszerzenie>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>package</id>
<phase>package</phase>
<configuration>
<tasks>
<move file="${nazwaPlikuWynikowego}.jar" tofile="${nazwaPlikuWynikowego}.${rozszerzenie}"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
W źródłach wtyczki maven-jar-plugin jest wyraźnie wskazane, że jedynym słusznym rozszerzeniem jest jar. Patrz org.apache.maven.plugin.jar.AbstractJarMojo.getJarFile(File basedir, String finalName, String classifier).
Zdaje się, że właśnie natrafiłem na ciekawy problem na długie i obfitujące w jedzenie, świąteczne wieczory.
p.s. Dzięki Szimano za niezłą zagadkę na zakończenie roku. Gratulacje humoru! ;-)
Heh dzieki :-). Ja przy okazji znalazlem cos innego.
OdpowiedzUsuńJesli pakujemy tego jara w eara, to konfiguracja ejbModule pozwala wybrac nazwe paczki, ktora bedzie w earze.
Takze mozna zrobic cos takiego:
<dependencies>
<dependency>
<groupId>org.jboss.labs</groupId>
<artifactId>core-model-ejb3</artifactId>
<version>1.0</version>
<type>ejb</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<modules>
<ejbModule>
<groupId>org.jboss.labs</groupId>
<artifactId>core-model-ejb3</artifactId>
<bundleFileName>core-model-ejb3.ejb3</bundleFileName>
</ejbModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
Można też bez antrun. W maven dependency plugin dla copy można podać outputAbsoluteArtifactFilename
OdpowiedzUsuńProblem ze zrobieniem paczki z jakimś wymyślnym rozszerzeniem faktycznie nie jest trywialny. Kiedyś straciłem parę godzin próbując użyć do tego assembly. Okazuje się że można dowolnie zdefiniować nazwę ale rozszerzenie już nie. Ale podobno "łatwo" da się dopisać mechanizm dla własnego... .Jak to z prawie wszystkim w mavenie :)
Jacku, jeżeli jest to jednorazowy przypadek to można użyć anta, ale jeżeli wiemy, że będzie on występował w kilku miejscach to najodpowiedniejsze jest napisanie pluginu. Zresztą sam pokazałeś jak można to zrobić. Zatem wystarczy "zerżnąć" kod z maven-jar-plugin odpowiednio go parametryzując.
OdpowiedzUsuńNo właśnie i to jest jeden z tych miliona przypadków, dla których NIE UŻYWAM Mavena... Najłatwiejsze rzeczy stają się wyzwaniem.
OdpowiedzUsuńPo co wogóle używać takich narzędzi skoro jest ANT + IVY?!?!? Z pobudek masochistycznych :)?
Artur
Artur,
OdpowiedzUsuńIVY+ANT bylo by piękną idealną alternatywą, szkoda tylko że puki co kiepsko sobie radzi z używaniem repozytoriów mavena... (np. wsparcie dla 'snapshots')
Artur, nie rozumiem Twojego podejścia. Używając mavena masz do dyspozycji zarówno potęgę mavenowych pluginów jak i elastyczność anta. Do standardowych rzeczy używasz mavena i naprawdę możesz je zrobić w oka mgnieniu, zaś do rzeczy niestandardowych używasz tasków antowych wywoływanych przez maven-antrun-plugin.
OdpowiedzUsuńNic nie tracisz, wiele zyskujesz.
Używając mavena zamiast jednego narzędzia masz w ręku dwa - każde ze swoimi mocnymi i słabymi stronami. Od Ciebie zależy które z nich i jak wykorzystasz.
W czym więc problem z używaniem mavena skoro niczego się w ten sposób nie pozbawiasz a wiele zyskujesz ?
pozdrawiam
Tomek