Come escludere una dipendenza dal progetto del genitore in Maven?

Question

Ad esempio, ho 2 progetti Maven. Uno è "genitore del progetto". L'altro è "progetto-bambino". Ovviamente, "project-child" è il sottoprogetto di "project-parent".

"project-parent" ha una dipendenza di log4j. Ma voglio escluderlo dal "progetto-bambino". C'è un modo?

Si potrebbe dire che dovrei spostare log4j da "project-parent" a "project-child". Questo è assolutamente corretto. Ma suppongo che NON POSSO modificare il POM di "project-parent".

Grazie in anticipo.

Answer 1

Penso che in Maven2 non ci sia modo di ottenere questo, perché questo è l'eredità POM per . Tuttavia, c'è un trucco che posso pensare:

Supponiamo che tu abbia il diritto di caricare artefatto nel tuo repository di risorse interne. È possibile creare un JAR vuoto, distribuirlo come log4j: log4j, con una versione ovviamente anormale (ad esempio log4j: log4j: 9999). Aggiungi tale dipendenza nel tuo progetto-figlio. Quindi sostituirà la dipendenza del genitore da un JAR in-fact-empty.

Answer 2

Se ho capito la domanda, ciò di cui hai bisogno è qualcosa come la seguente. Ottiene una dipendenza ed esclude tale dipendenza dall'aggiunta all'elenco delle dipendenze. Spesso questo viene utilizzato se si desidera iniettare una versione più recente di un pacchetto anziché quella a cui si fa riferimento nell'altro pacchetto.

<dependency> 
    <groupId>log4j</groupId> 
    <artifactId>log4j</artifactId> 
    <version>1.2.15</version> 
    <exclusions> 
     <exclusion> 
      <groupId>com.sun.jmx</groupId> 
      <artifactId>jmxri</artifactId> 
     </exclusion> 
     ... 
    </exclusions> 
    ... 

Se si sta invece parlando di un rapporto <parent> allora non sono sicuro che c'è un modo per farlo. Puoi passare da <parent> a <dependency>?

Answer 3

Non conosco un modo per escludere effettivamente una dipendenza, ma è possibile escluderlo dalla distribuzione di destinazione, ma è un po 'un trucco. È necessario modificare l'ambito della dipendenza in qualcosa che è possibile escludere nella distribuzione finale.

Quindi, dire che il mio genitore aveva una dipendenza da JUnit 4.8, nel mio pom dite:

<dependency> 
    <groupId>junit</groupId> 
    <artifactId>junit</artifactId> 
    <version>4.8</version> 
    <scope>provided</scope> 
</dependency> 

Quindi stiamo cambiando lo scopo di condizione. Per una spiegazione di come funziona, vedere la mia risposta allo NoClassDefFoundError: org/junit/AfterClass during annotation processing. Purtroppo, questo non pregiudica la build, ma quando si sta copiando le dipendenze per la distribuzione finale, è possibile utilizzare l'elemento di configurazione excludeScope di non copiare la dipendenza nella distribuzione finale:

<plugin> 
<artifactId>maven-dependency-plugin</artifactId> 

<executions> 
    <execution> 
     <id>copy-libs</id> 
     <phase>package</phase> 
     <goals> 
      <goal>copy-dependencies</goal> 
     </goals> 
     <configuration> 
      <outputDirectory>${project.build.directory}/lib</outputDirectory> 
      <excludeScope>provided</excludeScope> 
     </configuration> 
    </execution> 

Answer 4

Un modo hacky per fare ciò è necessario specificare la dipendenza in project-child ma con l'ambito 'test' (o qualsiasi altro ambito più leggero disponibile). Ciò "nasconderà" l'ambito specificato in project-parent in modo che sia disponibile solo per testare il codice e non disponibile per il codice non di test sia in fase di compilazione che in fase di esecuzione.

Mi sono imbattuto in questa caratteristica di errore principalmente per errore. Nel mio caso, il mio progetto-figlio aveva un fratello di progetto con una dipendenza da ambito "compilato", mentre il genitore di progetto aveva la stessa dipendenza specificata (effettivamente ereditata da un nonno) con ambito "fornito". project-child era un eseguibile che dipendeva dal fratello di progetto, quindi un NoClassDefFoundError veniva lanciato in runtime da project-sibling poiché veniva utilizzato il percorso di classe di runtime di project-child, che non includeva la dipendenza 'fornita'.Ho risolto questo problema spostando la dipendenza 'compilazione' da fratello di progetto a genitore di progetto in modo che la 'compilazione' potesse "nascondere" il "fornito".

Answer 5

Ho incontrato la stessa domanda proprio come te. Nel mio progetto, let call the pom pom è parent.pom. genitore definito il log4j, SLF4J come questo:

 <dependency> 
      <groupId>org.slf4j</groupId> 
      <artifactId>slf4j-api</artifactId> 
      <version>${slf4j-api.version}</version> 
     </dependency> 
     <dependency> 
      <groupId>log4j</groupId> 
      <artifactId>log4j</artifactId> 
      <version>${log4j.version}</version> 
     </dependency> 
     <dependency> 
      <groupId>org.slf4j</groupId> 
      <artifactId>jcl-over-slf4j</artifactId> 
      <version>${slf4j-api.version}</version> 
     </dependency> 

     <dependency> 
      <groupId>org.slf4j</groupId> 
      <artifactId>slf4j-log4j12</artifactId> 
      <version>${slf4j-log4j12.version}</version> 
     </dependency> 

progetto figlio invocano qualche dipendenza nel child.pom. Ma non voglio la dipendenza log4j-1.2.x e voglio aumentare la versione di slf4j.

Così. Aggiungo la dipendenza del genitore

<dependency> 
     <groupId>parent</groupId> 
     <artifactId>myartifactId</artifactId> 
     <version>${my parent version}</version> 
</dependency> 

e utilizzare esclusioni per rimuovere il log4j

<dependency> 
     <groupId>parent</groupId> 
     <artifactId>myartifactId</artifactId> 
     <version>${my parent version}</version> 
     <exclusions> 
      <exclusion> 
       <groupId>log4j</groupId> 
       <artifactId>log4j</artifactId> 
      </exclusion> 
     </exclusions> 
</dependency> 

e aggiungere in modo esplicito lo slf4j e la dipendenza di log4j2 nel pom bambino

<dependency> 
     <groupId>org.slf4j</groupId> 
     <artifactId>slf4j-api</artifactId> 
     <version>1.7.6</version> 
    </dependency> 
    <dependency> 
     <groupId>org.apache.logging.log4j</groupId> 
     <artifactId>log4j-slf4j-impl</artifactId> 
     <version>2.8.2</version> 
    </dependency> 
    <dependency> 
     <groupId>org.apache.logging.log4j</groupId> 
     <artifactId>log4j-api</artifactId> 
     <version>2.8.2</version> 
    </dependency> 

    <dependency> 
     <groupId>org.apache.logging.log4j</groupId> 
     <artifactId>log4j-core</artifactId> 
     <version>2.8.2</version> 
    </dependency> 

    <dependency> 
     <groupId>com.lmax</groupId> 
     <artifactId>disruptor</artifactId> 
     <version>3.3.4</version> 
    </dependency> 

poi utilizzare la dipendenza da mvn: albero a mostrare la lista delle dipendenze, ancora vedere il log4j

[INFO] +- org.apache.kafka:kafka_2.10:jar:0.8.2.0:compile 
[INFO] | +- com.yammer.metrics:metrics-core:jar:2.2.0:compile 
[INFO] | +- org.scala-lang:scala-library:jar:2.10.4:compile 
[INFO] | +- org.apache.zookeeper:zookeeper:jar:3.4.6:compile 
[INFO] | | +- org.slf4j:slf4j-log4j12:jar:1.7.5:compile 
[INFO] | | +- log4j:log4j:jar:1.2.17:compile 

bene, aggiungiamo le esclusioni che la dipendenza ... rimuovere questo ragazzo.

<dependency> 
     <groupId>org.apache.kafka</groupId> 
     <artifactId>kafka-clients</artifactId> 
     <version>0.10.1.1</version> 
     <exclusions> 
      <exclusion> 
       <groupId>log4j</groupId> 
       <artifactId>log4j</artifactId> 
      </exclusion> 
     </exclusions> 
    </dependency> 

quindi eseguire di nuovo il comando per controllare l'elenco delle dipendenze. OK! chiaro ~

speranza che può aiutare a:>