Composizione del progetto multimodule Maven per quanto riguarda la condivisione delle dipendenze

Question

Ci sono alcune domande simili, ma niente del genere. Come ti occupi di questa situazione (scenario tipico):

Un progetto di 8-11 progetti per bambini, con un artefatto/progetto genitore e un progetto principale che utilizza principalmente/dichiara quegli altri come moduli.

Il problema è che tutti i progetti "rigorosamente" condividono solo le dipendenze comuni, come testng, logging, apache commons and stuff. Ma sempre come 3 di loro usano il 50-60% degli stessi DEP specifici (Apache-Chemistry, Jackrabbit, Abdara, ecc.), Un altro 2-3 di loro usa anche il 50-60% delle stesse ma diverse dipendenze. E il principale usa molti degli stessi dep.

Non posso mettere quei deps "non restritti" condivisi nel progetto genitore affinché gli altri li ereditano. Quindi solo i DEP comuni sono ereditati. E ci sono tonnellate di dipendenze duplicate. E posso gestire solo le loro versioni tramite <dependencyManagement>.

Un'altra opzione è avere POM genitore che contenga la maggior parte delle dipendenze, ma i progetti di figli ereditano anche quelli di cui non hanno bisogno.

Potrei avere più di 1 progetto genitore, ma non è giusto. Anche l'eredità del progetto principale potrebbe essere Nightmare, perché non sai di quali dipendenze hanno bisogno il progetto, se non documentano/commenta correttamente la definizione POM principale.

Un altro modo è quello di creare artefatti POM che fungono solo da contenitori di dipendenza: dichiarano gruppi specifici di dipendenze, in modo che i moduli dichiarino semplicemente quelli per ottenere dipendenze transitive. Ma hey, vorresti schierarti e impegnare una sorta di

Onedepartifact che dichiara jackrabit, abdera, chemistry

Un altro departivaggio che dichiara htmlcleaner, google-api, tika

Terzo Dichiarazione di repartifatti spring, httpclient, selenium

È un grosso disastro, non sono sicuro di usare <dependencyManagement> Principalmente, sembra essere utile solo per la gestione delle versioni di dipendenza.

Stavo pensando di adattare lo sviluppo della mia app a "Maven MultiModule Design". Ma se si desidera creare servizi Spring/Beans, che usano solo varie librerie, in un modulo, non le implementate in un modulo diverso, solo perché usano la libreria che altri moduli utilizza anche :-)

Answer 1

Maven 3.1 dovrebbe risolvere questo problema introducendo "mixin". Nel frattempo, sembra che io possa ottenere la maggior parte delle funzionalità necessarie con l'uso corretto dei profili, come ho descritto in questo post sul blog:

http://weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/maven-pom-composition-means-profiles

Per favore fatemi sapere se lo trovi utile.

Answer 2

So che hai detto che potrebbe essere un incubo, ma sento fortemente l'eredità tra il tuo genitore Pom è la strada da percorrere.

Descrivo una buona struttura del progetto multi-modulo in questa risposta. Descrive anche l'utilizzo di un aggregatore e un'eredità della catena dei genitori.

Alcune cose che ti aiuteranno a mantenere le cose organizzate e sane ...

• Usare buone convenzioni di denominazione; Non chiamare solo i progetti dei genitori parent1 e parent2. Usa nomi che descrivono quale tipo di dipendenze e altre cose configurano in modo che sia intuitivo per le persone sapere quale usare quando.
• Utilizzare la funzionalità di rilascio/distribuzione di Maven in modo che questi siano in versione correttamente nel tuo repository e fanno sempre riferimento agli artefatti di versione fissa. Non usare le istantanee è il primo passo per avere build deterministiche e riproducibili. I problemi di debug quando le cose stanno cambiando al volo è molto difficile.
• Non fare affidamento su un file pom.xml per sapere quali dipendenze ha bisogno il tuo progetto. Questo ti porterà a evitare l'eredità e altre cose come i profili personalizzati. Dovresti usare il plugina-dipendenza-dipendenza Per eseguire queste attività di analisi. Ci sono comandi come mvn dependency:tree che ti mostra tutte le dipendenze di un progetto e mvn dependency:analyze che ti mostra dipendenze inutilizzate.

Speriamo che, con questo consiglio, l'eredità dei file POM genitore non sembrerà così complicata e da incubo. Buona fortuna!

Answer 3

Se si tratta principalmente di controllo della versione (numero) - perché non specificare solo la versione di dipendenza come proprietà nel progetto principale e utilizzarla nei progetti figlio, come

Genitore

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>foo.bar</groupId>
    <artifactId>maven-parent</artifactId>
    <version>0.0.1</version>
    <packaging>pom</packaging>

    <properties>
        <log4j.version>1.2.16</log4j.version>
    </properties>

</project>

Bambino

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>maven-parent</artifactId>
        <groupId>foo.bar</groupId>
        <version>0.0.1</version>
    </parent>

    <groupId>foo.bar</groupId>
    <artifactId>maven-child</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>${log4j.version}</version>
        </dependency>
    </dependencies>

</project>

Questa è una soluzione semplice che consente di specificare dipendenze specifiche del progetto con numeri di versione coerenti.