2012-04-10 19 views
5

tworzę .ear użyciu MavenJak dołączyć zależności do ucha bez wersji w nazwie pliku

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-ear-plugin</artifactId> 
    <version>2.6</version> 
    <configuration> 
    <finalName>wsformatter-ear</finalName> 
    <includeLibInApplicationXml>true</includeLibInApplicationXml> 
    <version>1.4</version> 
    </configuration> 
</plugin> 

wszystkie zależności w .ear wyglądać Joda-Time-1.6.2.jar, commons-io-1.4.jar itd.

Ale mam też zależności, które chcę mieć bez wersji. Na przykład, w jaki sposób mogę zrobić, że zależność slf4j-api-1.5.6.jar będzie wyglądać slf4j-api.jar w moim .ear

+0

Po co ci to potrzebne? – weekens

+1

Mam zależność od moich innych projektów. Wersje tych projektów zmieniają się bardzo często – Ilya

Odpowiedz

1

Zasadniczo nie można (bez niektórych hakowanie w konfiguracji wtyczek Mavena), a nawet jeśli możesz - po prostu nie rób tego. Podejście Mavena i filozofia na temat zależności są surowe i proste, w tym domyślna konwencja posiadania wersji jako sufiksu nazwy pliku. Od razu mówi, która wersja artefaktu jest używana. Jeśli jesteś zależny od jakiegoś artefaktu, który jest często uwalniany, musisz zaktualizować jego wersję w POM, tak, aby jej "propagacja" nie była w jakiś sposób samoczynna. Dlatego nie widzę problemu z tym przyrostkiem nazwy pliku.

Jeśli ta potrzeba częstych zmian jest dla ciebie problematyczna, może powinieneś rozważyć modyfikację w jakiś sposób tego często wydanego cyklu rozwoju artefaktów? Prawdopodobnie możesz wydłużyć nieco czas spędzony w tej samej wersji SNAPSHOT? Nawet jeśli często korzystasz z "wewnętrznych" wydań (takich jak nocne konstrukcje), Maven nie zmusza cię do podważania twojej wersji w każdym wydaniu (w sensie Maven Release Plugin). Możesz pozostać przy wersji SNAPSHOT tak długo, jak chcesz. Nawet w naprawdę szybkich procesach Agile (lub Kanban) tego rodzaju "prawdziwe" wydarzenie zwykle zdarza się co kilka tygodni i jest wystarczająco długie, aby można było nim zarządzać.

Podsumowując, nie jest tak, że nie pomogę ci (lub coś podobnego) lub nie chcę. Po prostu myślę, że próbujesz walczyć z Mavenem. Maven jest naprawdę potężny, jeśli akceptujesz jego podejście i konwencje. Z mojego doświadczenia wynika, że ​​próba obejścia tego problemu oznacza problemy (prędzej czy później). Widziałem już wiele projektów, które miały konfigurację Maven-like-Ant i wielu programistów narzekało na to, że Maven jest do bani. Po zastanowieniu się nad tym, powiedziałem im: "Maven nie jest do dupy, twoje POM".

+0

Jednym z powodów, aby to zrobić jest: Numery wersji łamią odwołania w pliku persistence.xml, ponieważ muszą odwoływać się do konkretnej nazwy pliku, która jest niemożliwa do poznania z mediacją zależności Maven (nie mogę być pewien, że mój inny plik-1.0.0.jar faktycznie będzie częścią ucha, może zostanie zastąpiony przez inny-1.0.1.jar). –

16

Całkowicie zgadzam się z Michałem Kalinowskim. Ale znalazłem się w tej samej sytuacji, właściwie w rzeczywistości odwrotnej - ktoś skonfigurował projekt, aby wykluczyć wersje z ostatecznej wersji EAR i szukałem sposobu na anulowanie tego, ponieważ było to sprzeczne ze stylem życia maven, więc " szukałem w Internecie i znalazłem to pytanie, ale odpowiedź znalazłem w samym kodzie. można użyć:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-ear-plugin</artifactId> 
    <configuration> 
     <version>5</version> 
    <defaultLibBundleDir>lib</defaultLibBundleDir> 
    <fileNameMapping>no-version</fileNameMapping> 
    </configuration> 
</plugin> 

wiersz z tagiem fileNameMapping to, co chcesz. Mam nadzieję, że to pomoże.

Powiązane problemy