Specificare classpath per Maven

Question

abbastanza nuovo per Maven qui quindi lasciatemi spiegare prima quello che sto cercando di fare:

Abbiamo alcuni file JAR che non verranno aggiunti al repo. Questo è perché sono specifici per Oracle ADF e sono già immessi sul nostro application server. C'è solo 1 versione da usare per tutte le applicazioni in fase di nessuno. Per compilare, però, abbiamo bisogno di avere questi sul percorso della classe. Ci sono un sacco di questi vasi, quindi se dovessimo effettuare l'aggiornamento a una nuova versione di ADF, avremmo dovuto andare in ogni applicazione e ridefinire alcune dipendenze ridondanti belle. Così ancora una volta, il mio obiettivo è quello di aggiungere solo questi vasi al classpath, dal momento che ci sarà il controllo quale versione viene effettivamente utilizzato altrove.

Quindi, fondamentalmente, voglio aggiungere solo ogni JAR in una data directory rete (di cui gli sviluppatori non hanno il permesso di modificare) al classpath di Maven per quando si compila. E senza mettere qualsiasi di questi file JAR in un repository. E, naturalmente, questi vasi sono di non essere confezionati a qualsiasi orecchio / WAR.

modifica

Tra gli altri motivi per cui non voglio aggiungere questi per il repo aziendale è che:

1. questi vasi non sono utilizzati da qualsiasi altra cosa. Ci sono un sacco di loro, non comune ed esclusivo per Oracle.
2. Non ci sarà solo una versione di un dato JAR utilizzato al momento nessuno. Non ci sarà mai il caso in cui l'applicazione A dipende da 1.0 e applicazioni B dipende da 1.1. Sia App A e B dipenderanno sia 1.1 o 1.2 solo.
3. Abbiamo in programma di mantenere oltre 100 applicazioni. Questo è un sacco di file pom.xml, il che significa in qualsiasi momento aggiorniamo Oracle ADF, se una dipendenza non è stato specificato correttamente (via errore umano) dovremo correggere ogni errore ogni volta che modificare i file pom.xml 100 + per un l'aggiornamento.

Answer 1

Vedo tre opzioni:

1. Mettere le dipendenze in un repository (potrebbe essere un repository di file come descritto in questa risposta ) e di dichiarare con un provided ambito.
2. Utilizza lo sporco system ambito trick (vale a dire dichiarare le dipendenze con un ambito di sistema e impostare il percorso per i barattoli nel file system.
3. Little variazione di # 2:. Creare un vaso con un MANIFEST.MF riferimento tutti i vasetti (utilizzando un percorso relativo) e dichiarare una dipendenza da questa giara quasi vuota con una portata system

Il modo pulito è l'opzione # 1, ma altri potrebbe funzionare anche nel tuo caso. Opzione # 3 sembra essere il più vicino a quello che stai cercando.

Aggiornamento: Per chiarire l'opzione # 3

Diciamo che si dispone di una directory con a.jar e b.jar . Creare un c.jar con una voce Class-Path nella sua META-INF/MANIFEST.MF messa in vendita di altri vasi, qualcosa di simile a questo:

Class-Path: ./a.jar ./b.jar 

Quindi dichiarare una dipendenza nella vostra POM su c (e solo su c) con un ambito system, altri vasi diventano "visibili" senza doverli elencare esplicitamente in POM (certo, è necessario dichiararli nel manifesto ma questo può essere molto facilmente script).

Answer 2

Anche se è esplicitamente dichiarato che non li vogliono nel repository, le motivazioni non sono giustificati. Ecco il mio consiglio:

• installare questi vasi in repostory
• li aggiungere come Maven dipendenze, con <scope>provided</scope>. Ciò significa che essi sono forniti dal runtime (l'application server) e non saranno incluse nella vostra artefatti (guerra / orecchio)

questa domanda simile

E 'consigliabile che un'organizzazione che sta usando Maven ampiamente ha un proprio repository. Si può vedere Nexus . Quindi è possibile installare questi vasetti nel repository e tutti gli sviluppatori li userete, piuttosto che avere i barattoli in un solo ogni repository locale.

(non l'opzione "più brutto" sarebbe quella di utilizzare Maven a tutti, mettere mettere i vasi in una posizione relativa e aggiungerli al classpath del progetto, presentando il file delle proprietà percorso di classe (a seconda del IDE))

Answer 3

se si sta sviluppando ADF (10g / 11g immagino) componenti, suppongo che verrà usato come JDeveloper IDE. JDeveloper è dotato di una ricca biblioteca strumento di gestione che consente di definire quale libaries sono necessari per la compilazione o quali dovrebbero essere imballati per la distribuzione. Mi immagino già saprete come aggiungere le librerie a progetti e indicare nel profilo distribuzione quali dovrebbero essere raccolti durante il confezionamento. Se si desidera mantenere le librerie di Maven, forse questo potrebbe essere l'approccio migliore. Mettiamoci dicono che le librerie si fa riferimento sono anche i "Webcenter" quelli, utilizzando questo approccio vi garantirà di avere le librerie adeguate come JDeveloper sarà disponibile con i giusti librerie di versione.

Tuttavia, come si utilizza Maven non mi consiglia di tenere alcune librerie fuori controllo e repository Maven. Io consiglierei di scegliere tra Maven e gestione della libreria Oracle JDeveloper. Nel nostro progetto attuale stiamo lavorando con JDeveloper 11g ADF (e WebCenter) e usiamo Maven, semplicemente ci fanno più facile la gestione della libreria. Alla fine della giornata, avremo una grande quantità di librerie di terze parti (dire Apache, Primavera, etc.) che sono utili per essere gestito da Maven e non così tante librerie Oracle realmente necessari per la compilazione nell'IDE (come si avrebbe solo bisogno quelle API e non le loro implementazioni). Il nostro approccio è stato quello di aggiungere le librerie Oracle al nostro repository Maven ogni volta che sono necessari e lasciare che Maven per controllare l'intera gestione delle dipendenze.

Come altri dicono nelle loro risposte se non volete le dipendenze da inserire in uno dei tuoi artefatti usare <scope>provided</scope>. Una volta configurato il proprio ambiente di sviluppo sarà grato Maven fa il lavoro e si può (quasi) dimenticare gestione delle dipendenze. Per costruire il JDeveloper IDE file stiamo usando il Maven jdev plug-in, in modo da mvn jdev:jdev avrebbe costruito generare i nostri file di progetto e impostare le dipendenze da librerie e tra di loro per compilare correttamente.

Aggiornamento:

Naturalmente, è necessario fare riferimento alle librerie ADF nei file pom. Nel nostro progetto abbiamo appena riferiamo a quelli utilizzati per una specifica applicazione, dire ADF Tag biblioteche o di un servizio specifico, non l'intero ADF / WebCenter stack. A questo scopo utilizzare il campo di applicazione "a condizione". È ancora possibile lasciare JDeveloper per gestire le librerie, ma abbiamo scoperto che è più semplice avere o un 100% le librerie JDeveloper avvicinano o un approccio Maven 100%. Se si va con l'approccio Maven ci vorrà del tempo per costruire la vostra repo locale in un primo momento, ma una volta fatto è molto facile da mantenere, e l'intero ciclo (sviluppo, costruire, testare, il confezionamento e la distribuzione) sarà più semplice, avente una configurazione più coerente. E 'vero che in un futuro si dovrà aggiornare alle versioni successive ADF, ma come sarà già definita la struttura del repository dovrebbe essere qualcosa di veloce. Per gli aggiornamenti futuri vi consiglio di mantenere la versione ADF come una proprietà sulla parte superiore pom, che vi permetterà di passare velocemente a una nuova versione.