Condivisione della configurazione delle dipendenze su più progetti (Maven)

Question

Condivisione della configurazione delle dipendenze su più progetti (Maven)

#1 da (3 voti)

2

Da un grande repository SVN vogliamo passare a Maven / Gradle per gestire le dipendenze in modo che i programmatori possano lavorare con un singolo progetto senza verificare il tutto.

Stiamo scrivendo plugin per un server (la sua interfaccia). Alcuni dei nostri plug-in dipendono da altri plugin installati anche sul server. Quindi i nostri plugin dovrebbero essere sempre costruiti rispetto alle versioni che sono attualmente (o che saranno) utilizzate sul server.

Per esempio, diciamo che il mio plugin A dipende da un plugin esterno B. Oggi B è installato con la versione 1.2.3, ma domani potrebbe essere installato con 1.2.4. Quando si costruisce A è importante costruire sempre contro la versione giusta.

Il mio problema è che abbiamo centinaia di plugin come A, quindi sarebbe quasi impossibile aggiornare manualmente le versioni di tutte le dipendenze solo se un plugin come B viene utilizzato con una nuova versione.

Ora ho pensato a due opzioni anche se non sono sicuro di come ottenerle.

Utilizzo di una sorta di configurazione globale per le versioni di dipendenza (nessuna idea se o come ciò potrebbe essere fatto)
Ospitando sempre gli artefatti usati correnti in un repository separato

Global resolver resolver
Dato che sono nuovo a Maven, non so se questa potrebbe essere una soluzione possibile o addirittura accettabile. Ho solo pensato di creare un qualche tipo di artefatto, che contenga tutte le dipendenze che i plugin come A potrebbero avere. La cosa veramente brutta (anche se funzionerebbe) è che il plugin A avrebbe delle dipendenze di cui non ha veramente bisogno.

Configurazione della versione globale
Poi ho pensato a un modo per dire a Maven / Gradle quale sia l'ultima versione di dipendenza di un artefatto specifico. Non so se questo è possibile o se questo porterebbe ad altri problemi.

Hosting degli artefatti Al momento sto testando l'hosting delle dipendenze esterne su un repository separato come istantanee in modo che i nostri plugin possano risolverli sempre alla versione più alta disponibile. Attualmente questo porta a problemi quando si risolvono le dipendenze dalle dipendenze, ma suppongo che ho appena sbagliato qualcosa nella configurazione. Tuttavia non sono sicuro se questo potrebbe essere un modo giusto per andare.

Spero che tu capisca di cosa abbiamo bisogno, quindi potresti darmi alcuni consigli o parole chiave per concetti che potrebbero risolvere il nostro problema. Vogliamo passare a un sistema di gestione delle dipendenze (al momento tutte le dipendenze sono incluse localmente) ma tutte le opzioni sembrano più complicate rispetto al nostro repository incasinato.

maven dependency-management gradle

posta K. D. 11.02.2015 - 17:17

fonte

1 risposta

Leggi altre domande sui tag maven dependency-management gradle

Un'applicazione dovrebbe recuperare da un'eccezione generata in PHP? Gestione dei tipi e delle conversioni in un compilatore

score 3 · Accepted Answer

Se comprendo chiaramente la tua situazione, sembra che tu abbia molti artefatti di tipo A Maven, e questi per lo più definiscono una dipendenza da alcune risorse di tipo B.

Gli artefatti di tipo A sono prodotti dal tuo gruppo di sviluppo. Gli artef di tipo B di cui A dipende da un gruppo esterno. I tuoi ambienti di runtime per Artefacts di tipo A e B avranno già raggruppati in essi gli Artifacts B.

Il problema è che quando la versione di un oggetto B cambia sul server, non si vuole essere disturbati dall'aggiornamento manuale di molti file POM con tutte le modifiche delle dipendenze avvenute inizialmente in B.

Il tuo primo suggerimento penso sia l'approccio migliore:

I just thought about creating some kind of artifact, that contains all the dependencies that plugins like A could have.

Puoi assolutamente farlo ed è una pratica accettata. Quello che fai è definire un file POM padre che dichiari tutte le dipendenze di cui potrebbe avere bisogno un artefatto di tipo A. Questo file POM principale può essere distribuito nel repository Maven in quanto è un modulo univoco Group, Artifact e Versioned. Questo modulo POM padre può quindi essere referenziato nei file POM dei tuoi progetti di tipo A usando l'elemento <parent> . Il vantaggio è che è possibile aggiornare tutte le versioni dei plug-in di tipo B nel progetto padre e ripristinare solo il padre POM. Ora i tuoi POM di tipo A devono solo aggiornare il loro numero di versione se vogliono ottenere le nuove dipendenze. Per ulteriori informazioni sui progetti padre POM vedi sotto.

link

The really bad thing (even if this would work) is that plugin A would have dependencies it does not really need.

Ma vedi che in realtà non è una brutta cosa!

<dependency>
  ...
  <scope>provided</compile>
</dependency>

L'utilizzo dell'ambito fornito su una dipendenza da un plugin B sta fondamentalmente dicendo a Maven che utilizzerà SOLO questo artefatto per compilare fonti e test di unità. Ignorerà la dipendenza in modo specifico durante il confezionamento del manufatto di build con il presupposto che JDK o il contenitore dell'applicazione forniranno questo per il plug-in durante il runtime.

link

Se alcune delle dipendenze non vengono utilizzate, non importa. Non verranno raggruppati, vengono solo scaricati e utilizzati per compilare ed eseguire casi di test.