Rilevamento di dipendenze incompatibili in Maven?

Supponiamo che tu abbia un set di app web che usano varie versioni di una libreria comune come Spring. Ho una libreria di business logic che usa anche questa libreria comune. Finora nessun problema, ma lungo il cammino una versione della libreria comune ha cambiato una definizione astratta della classe e ha rotto la libreria logica aziendale.Rilevamento di dipendenze incompatibili in Maven?

così finisco con un tavolo versione compatibile che assomiglia a questo ...

business-lib-version | common-lib-version 
     1.0   |  1.0 
     1.1   |  2.0

non voglio la versione business lib per guidare la versione lib comuni nell'applicazione consumare. Piuttosto mi piacerebbe scegliere la versione corretta del business lib basato sulla lib comune. Sono abbastanza sicuro che non è possibile, quindi passo alla domanda principale.

C'è un modo elegante per rilevare incompatibilità di versione? Idealmente mi piacerebbe una soluzione di tempo di costruzione, altrimenti una soluzione di run-time potrebbe essere ok.

Ho provato a utilizzare gli intervalli di versioni in Maven ma questo ci ha causato molti problemi a causa di come Maven ordina le versioni in formati di versione non standard e abbiamo anche avuto vari problemi nella risoluzione degli intervalli correttamente al momento della compilazione.

fonte

2012-03-01 Andrew White

Per "incompatibilità" intendete semplicemente versioni diverse o rottura effettiva? –

@DaveNewton: uno o entrambi in questo punto. Sto semplicemente cercando la soluzione di meno sorprese. –

Il plug-in Ning dependency-versions-check Maven fallirà la tua build se una versione di dipendenza è stata accidentalmente trattenuta da un'altra dipendenza. Non lo aggiusterà per te, ma almeno te lo dirà!

fonte

2012-03-01 17:20:32

Il problema qui è che richiede che l'app che consuma abbia quel plugin incluso. Forse potrebbe essere aggiunto a una build di ambiente CI standard. Temo che questo potrebbe rompere altre dipendenze che sono ok con l'utilizzo di una versione più recente. Ho ancora molto da leggere nei documenti però. –

Lo includiamo in una "base" che tutti i nostri progetti ereditano, quindi tutti i progetti la ottengono (e anche altre configurazioni) –

Per quanto riguarda il controllo delle versioni, si presuppone che si disponga di una politica di versione sensibile effettivamente seguita (ad es. minor.patch) e quindi ti consente di tornare dalla versione 1.7.2 alla 1.7.1 ma non di tornare alla versione 1.6.9 –

Non conosco alcun modo per farlo bene, sia in fase di esecuzione che in fase di costruzione. Non esiste un meccanismo standard per determinare la versione dei pacchetti senza indagare sui manifesti o sui nomi dei file jar, il che sarebbe un trucco al meglio. Forse c'è un plugin di Maven che non so di questo in modo automatico ma non ne conosco uno.

Abbiamo appena corretto le versioni di quali librerie abbiamo bisogno per il nostro codice e l'aggiornamento quando è necessario perché abbiamo bisogno di funzionalità aggiuntive o di un'altra dipendenza. In genere siamo davanti altre dipendenze così abbiamo messo un marker tipico di esclusione nelle nostre definizioni di dipendenza nel pom.xml:

<dependency> 
    <groupId>org.springframework</groupId> 
    <artifactId>spring</artifactId> 
    <version>${spring-version}</version> 
    <exclusions> 
     <exclusion> 
      <groupId>commons-logging</groupId> 
      <artifactId>commons-logging</artifactId> 
     </exclusion>

Questo ci permette di dipendere da una versione successivadi commons-logging.

Se, tuttavia, si utilizza 1.0 di una libreria ma una delle proprie dipendenze utilizza 2.0, è necessario provare lo exclusion e verificare se la dipendenza viene eseguita con 1.0 o anche con la compilazione. In caso contrario, sarà necessario aggiornare il codice per lavorare con 2.0 o eseguire il downgrade della dipendenza.

Siamo spiacenti che non potrei essere più di aiuto.

fonte

2012-03-01 16:47:31 Gray

Rilevamento di dipendenze incompatibili in Maven?

risposta

Problemi correlati