2012-03-21 11 views
24

Qualcuno ha idea di cosa sia successo alla mia build di maven? Ricevo un sacco di avvertimenti duplicati.Maven build [WARNING] abbiamo una classe duplicata

[WARNING] We have a duplicate org/apache/commons/logging/impl/LogFactoryImpl$1.class in /home/shengjie/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar 
[WARNING] We have a duplicate org/apache/commons/logging/impl/LogFactoryImpl.class in /home/shengjie/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar 
[WARNING] We have a duplicate org/apache/commons/logging/impl/NoOpLog.class in /home/shengjie/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar 
[WARNING] We have a duplicate org/apache/commons/logging/impl/SimpleLog$1.class in /home/shengjie/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar 
[WARNING] We have a duplicate org/apache/commons/logging/impl/SimpleLog.class in /home/shengjie/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar 
[WARNING] We have a duplicate org/apache/commons/logging/impl/Jdk14Logger.class in /home/shengjie/.m2/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar 

Ho guardato nel mio repo m2 locale, ho due classi non in vaso commons-logging-api, LogFactoryImpl.class e LogFactoryImpl $ 1.class. Come tutte le classi menzionate negli avvertimenti.

Una cosa da dire è che sto usando il plugin ombra nel mio pom.xml.

 <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-shade-plugin</artifactId> 
      <version>1.4</version> 
      <configuration> 
       <createDependencyReducedPom>true</createDependencyReducedPom> 
       <filters> 
        <filter> 
         <artifact>*:*</artifact> 
         <excludes> 
          <exclude>META-INF/*.SF</exclude> 
          <exclude>META-INF/*.DSA</exclude> 
          <exclude>META-INF/*.RSA</exclude> 
         </excludes> 
        </filter> 
       </filters> 
      </configuration> 
      <executions> 
       <execution> 
        <phase>package</phase> 
        <goals> 
         <goal>shade</goal> 
        </goals> 
        <configuration> 
         <transformers> 
          <transformer 
           implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" /> 
          <transformer 
           implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> 
           <mainClass>com.~~~~black out my own main class here~~~~~</mainClass> 
          </transformer> 
         </transformers> 
        </configuration> 
       </execution> 
      </executions> 
     </plugin> 

ho notato che l'albero delle dipendenze sembra come di seguito

[INFO] +- org.apache.cxf:cxf-bundle-jaxrs:jar:2.5.1:compile 
[INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile 
[INFO] \- org.apache.hadoop.hive:hive-jdbc:jar:0.7.1-cdh3u3:compile 
[INFO] \- org.apache.hadoop.hive:hive-common:jar:0.7.1-cdh3u3:compile 
[INFO]  \- commons-logging:commons-logging-api:jar:1.0.4:compile 

e commons-logging.jar e commons-logging-api.jar entrambi hanno org/apache/comuni/logging/LogFactory. classe.

in qualche modo il plugin Shad sta provando a comprimerli in un grosso barattolo di grasso alla fine. allora l'avviso sta mostrando. È stato detto che questo è un avvertimento ignorabile. Ma sono un po 'preoccupato, come fa l'applicazione a sapere quale dovrebbe essere la classe esatta se ci sono due classi duplicate con lo stesso nome?

+1

LogFactoryImpl.class e LogFactoryImpl $ 1.class la classe con $ 1 nel nome è la classe locale all'interno di LogFactoryImpl. – khmarbaise

risposta

8

Dai un'occhiata alla sezione "Esclusioni dipendenze" nello Maven doc.

Nell'esempio fornito, escluderò la dipendenza commons-logging:commons-logging-api:jar:1.0.4:compile da org.apache.hadoop.hive:hive-common:jar:0.7.1-cdh3u3:compile. Nel tuo pom.xml:

<dependency> 
     <groupId>org.apache.hadoop.hive</groupId> 
     <artifactId>hive-common:jar</artifactId> 
     <version>0.7.1-cdh3u3</version> 
     <exclusions> 
      <exclusion> 
       <groupId>commons-logging</groupId> 
       <artifactId>commons-logging-api</artifactId> 
      </exclusion> 
     </exclusions> 
    </dependency> 
+0

Grazie mille, questo ha senso. quindi qual è il modo migliore per gestire le dipendenze in questo modo. diciamo che hai projectA.jar, projectB.jar, hanno le stesse dipendenze in diverse versioni. per esempio. dependency.1.0, dependency.2.0. Rischia di usarne solo uno. C'è un modo per consentire a ProjectA di continuare a utilizzare depdency.1.0 mentre ProjectB utilizza ancora dependency.2.0? – Shengjie

+1

No, non c'è modo (forse con OSGI ma non sono un esperto in questo settore). In questo caso, è il programma di caricamento classi che seleziona la classe da utilizzare (a seconda del sistema operativo, della JVM ecc., È spesso il primo jar a cui viene fatto riferimento nel classpath utilizzato). La cosa migliore è prendere l'ultima versione (escludere altre versioni), sperando che sia compatibile con le versioni precedenti ... Ma è meglio che lasciare che il classloader scelga per te. –

0

Hai dipendenze nel pom che contengono classi duplicate ma senza il pom appropriato non posso dire una parola a riguardo.

+0

ha aggiunto più informazioni, puoi dargli un'occhiata di nuovo? Grazie – Shengjie

+0

Hai controllato quale delle dipendenze contiene le classi duplicate? In base all'output di commons-logging-api-1.0.4.jar che sembrava provenire dall'utilizzo di una versione API diversa (duplicata) o si sta utilizzando un altro provider di registrazione (slf4j?). – khmarbaise

8

Si potrebbe anche avere una limitazione di plug-in maven-shader. Sostituisce l'artefatto jar predefinito (creato da maven-jar-plugin). Funziona bene su una build pulita, ma su una ricostruzione in cui il jar non viene rigenerato, lo shader viene eseguito di nuovo sul jar creato l'ultima volta, che contiene già copie di tutte le dipendenze della classe. Ciò produce molti avvertimenti sui duplicati.

Questo problema è ancora irrisolto, come di Maven-Shader-Plugin 2.0: http://jira.codehaus.org/browse/MSHADE-126

Una soluzione è quella di aggiungere il Maven-jar-plugin in modo esplicito al tuo pom.xml e aggiungere l'impostazione <forceCreation>true</forceCreation> configurazione.

+0

Questo è ciò che l'ha causato per me. Puoi risolverlo seguendo la soluzione qui: http://stackoverflow.com/questions/8880361/superfluous-warnings-when-using-maven-shade-plugin – stantonk

3

Nel mio caso, il mio padre padre includeva commons-beanutils e il mio modulo figlio (che è l'unica cosa che volevo compilare) includeva commons-io.

Il plug di schermo si è lamentato dei duplicati poiché commons-io e commons-beansutil condividevano alcune classi comuni. Si noti che beanutiul è stato incluso anche se non era necessario e non è stato utilizzato.

risolvo questo riducendo al minimo il barattolo con l'aggiunta di questo alla configurazione:

<minimizeJar>true</minimizeJar> 

Ora il plugin ombra non aggiungere risorse inutilizzate.

L'avviso è andato via.

1

È possibile escludere il vaso non si desidera (quelli che stanno dando gli avvertimenti duplicato utilizzando i seguenti tag sotto il plugin ombra -

<configuration> 
    <artifactSet> 
     <excludes> 
     <exclude>commons-logging:commons-logging</exclude> 
     </excludes> 
    </artifactSet> 
    <minimizeJar>true</minimizeJar> 
    </configuration> 

Maggiori dettagli possono essere trovati a http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html

0

ho visto questo accadere in eclissi, quando ho aggiornato dipendenze del mio progetto principale.

ho cancellato tutti i file nella mia directory di destinazione e risolto i problemi.

0

Tutto sopra (sulla revisione dell'albero delle dipendenze ed escluso) è corretto nella maggior parte dei casi, ma nel mio caso (non avevo sovrapposizioni nelle mie dipendenze) preliminari clean aiutato (non so perché però):

mvn clean package

0

Nel mio caso mi sono basato su un pacchetto che crea anche un vaso ombreggiato.

I jar ombreggiati sono pensati per l'implementazione, non per l'installazione come dipendenza.

Creazione di una POM di dipendenza ridotta durante il processo di generazione della dipendenza, indica maven su cui è possibile tralasciare le dipendenze.

Nella configurazione Maven-ombra-plugin:

<configuration> 
    <createDependencyReducedPom>false</createDependencyReducedPom> 
</configuration> 

Per maggiori dettagli si veda questo post:

What is the maven-shade-plugin used for, and why would you want to relocate java packages?

L'errore mi è stato sempre da Maven:

ATTENZIONE: x.jar, y.jar contengono classi sovrapposte

Problemi correlati