2012-04-10 14 views
5

sto creando .ear usando MavenCome includere le dipendenze in un EAR, senza di versione nel nome del file

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

Tutte le dipendenze nel .ear assomigliare Joda-tempo-1.6.2.jar, commons-io-1.4.jar ecc.

Ma anche, ho delle dipendenze, che voglio avere senza versione. Ad esempio, come posso fare, che la dipendenza slf4j-api-1.5.6.jar sarà simile slf4j-api.jar nel mio .ear

+0

Perché ne hai bisogno? – weekens

+1

Ho dipendenza dai miei altri progetti. Le versioni di questi progetti cambiano molto spesso – Ilya

risposta

1

In sostanza, non è possibile (senza qualche tipo di hacking sulla configurazione dei plug-in di Maven) e anche se potessi - non farlo. L'approccio e la filosofia di Maven riguardo alle dipendenze sono rigorose e drastiche, inclusa la convenzione di default di avere la versione come suffisso del nome file. Dirà immediatamente quale versione del manufatto è usata. Se dipendi da qualche artefatto che viene spesso rilasciato, devi comunque aggiornare la sua versione nel POM del tuo EAR, quindi la sua "propagazione" non è in qualche modo auto-attuante. Pertanto, non vedo alcun problema con questo suffisso di nome file.

Se questa necessità di modifiche frequenti è problematica per voi, forse dovreste considerare di modificare in qualche modo questo ciclo di sviluppo di artefatto frequentemente rilasciato? Probabilmente potresti allungare un po 'il tempo trascorso durante la stessa versione di SNAPSHOT? Anche se fai frequenti rilasci "interni" (come nightbuilds), Maven non ti obbliga a sbalzare la tua versione ogni versione (nel senso di Maven Release Plugin). Puoi stare con una versione di SNAPSHOT per tutto il tempo che vuoi. Anche nei processi Agile (o Kanban) molto veloci questo tipo di rilascio "reale" di solito accade ogni poche settimane ed è lungo abbastanza per essere gestibile.

Alla fine, non è così Non ti aiuterò (o qualcosa del genere) o non voglio. Penso solo che stai cercando di andare contro Maven. Maven è davvero potente se accetti e segui il suo approccio e le sue convenzioni. Dalla mia esperienza, cercare di aggirare questo significa problemi (prima o poi). Ho già visto molti progetti con configurazione di tipo Maven-Ant e molti sviluppatori si lamentano del fatto che Maven fa schifo. Dopo aver scoperto le cose lì, le ho dette: "Maven non fa schifo, le tue POM fanno".

+0

Un motivo per farlo è il seguente: I numeri di versione si rompono i riferimenti nel persistence.xml perché devono fare riferimento a un nome di file concreto che è impossibile conoscere con la mediazione di dipendenza Maven (non posso essere certo che il mio altro-1.0.0.jar sarà effettivamente parte dell'orecchio, forse è sostituito da altro-1.0.1.jar). –

16

Sono assolutamente d'accordo con Michal Kalinowski. Ma sono caduto nella stessa situazione, beh, in realtà una situazione inversa - qualcuno ha configurato il progetto per escludere le versioni nell'EAR finale e stavo cercando un modo per cancellare questo, perché era contro lo stile di vita del maven, quindi io Ho cercato nel web e trovato questa stessa domanda, ma la risposta che ho trovato nel codice stesso. È possibile utilizzare:

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

La linea con il tag fileNameMapping è ciò che si desidera. Spero che questo possa aiutare.

Problemi correlati