Pytanie Budowa Mavena [OSTRZEŻENIE] mamy zduplikowaną klasę


Ktoś ma pojęcie, co stało się z moim mavenem? Otrzymuję wiele duplikatów ostrzeżeń.

[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

Zajrzałem do mojego lokalnego repozytorium m2, mam dwie klasy w słoiku commons-logginging-api, LogFactoryImpl.class i LogFactoryImpl $ 1.class. To samo, co wszystkie klasy wymienione w ostrzeżeniach.

Warto wspomnieć, że używam wtyczki cieni w moim 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>

Zauważyłem, że drzewo zależności wygląda jak poniżej

[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

i commons-logging.jar i commons-logging-api.jar mają zarówno org / apache / commons / logging / LogFactory.class.

w jakiś sposób wtyczka Shad próbuje wcisnąć je do dużego słoja na końcu. wtedy pojawia się ostrzeżenie. Mówi się, że jest to ostrzeżenie niezrozumiałe. Ale trochę się martwię. Skąd aplikacja wie, jaka dokładnie klasa powinna być używana, jeśli istnieją dwie zduplikowane klasy o tej samej nazwie?


26
2018-03-21 10:30


pochodzenie


LogFactoryImpl.class i LogFactoryImpl $ 1.class klasa z $ 1 w nazwie jest lokalną klasą wewnątrz LogFactoryImpl. - khmarbaise


Odpowiedzi:


Spójrz na "Wyłączenia zależności" w sekcji Maven doc.

W podanym przykładzie wykluczę commons-logging:commons-logging-api:jar:1.0.4:compile zależność od org.apache.hadoop.hive:hive-common:jar:0.7.1-cdh3u3:compile. W twoim 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>

9
2018-03-21 15:34



Wielkie dzięki, to ma sens. więc jaki jest najlepszy sposób zarządzania zależnościami takimi jak ta. załóżmy, że masz projectA.jar, projectB.jar, mają te same zależności w różnych wersjach. na przykład. dependency.1.0, dependency.2.0. Ryzyko polega na użyciu jednego z nich. Czy istnieje sposób, aby program ProjectA nadal używał depdency.1.0, podczas gdy ProjectB nadal używa zależności.2.0? - Shengjie
Nie, nie ma mowy (może z OSGI, ale nie jestem ekspertem w tej dziedzinie). W tym przypadku jest to moduł ładujący klasy, który wybiera klasę do użycia (w zależności od systemu operacyjnego, maszyny JVM itd.), Często jest to pierwszy słoik, do którego odwołuje się użyta ścieżka klas). Najlepiej jest pobrać najnowszą wersję (wykluczyć inne wersje), mając nadzieję, że jest ona kompatybilna wstecz ... Ale jest to lepsze rozwiązanie niż pozwolenie na to, aby klasa ładujący wybrała dla ciebie. - nico_ekito


Możliwe, że napotkasz również ograniczenie wtyczki maven-shader. Zastępuje domyślny artefakt słoika (stworzony przez maven-jar-plugin). Działa to dobrze na czystej kompilacji, ale przy przebudowie, w której słoik nie jest regenerowany, moduł cieniujący działa ponownie w słoiku, który został utworzony po raz ostatni, który zawiera już kopie wszystkich zależności klas. Daje to wiele ostrzeżeń o duplikatach.

Ten problem nie został jeszcze rozwiązany, jak maven-shader-plugin 2.0: http://jira.codehaus.org/browse/MSHADE-126

Jednym z rozwiązań jest jawne dodanie wtyczki maven-jar do pliku pom.xml i dodanie ustawienia konfiguracyjnego <forceCreation>true</forceCreation>.


10
2018-04-02 21:30



To właśnie spowodowało to dla mnie. Możesz go rozwiązać, podążając za rozwiązaniem tutaj: stackoverflow.com/questions/8880361/... - stantonk


W moim przypadku, mój rodzic pom zawierał commons-beanutils, a mój moduł potomny (który jest jedyną rzeczą, którą chciałem skompilować) zawierał commons-io.

Wtyczka cienia narzekała na duplikaty, ponieważ commons-io i commons-beansutil dzieliły pewne wspólne klasy. Zauważ, że beansutiul został uwzględniony, mimo że nie był potrzebny i nie był używany.

Rozwiązuję to, minimalizując słoik, dodając to do konfiguracji:

<minimizeJar>true</minimizeJar>

Teraz wtyczka do cieni nie dodawała niewykorzystanych zasobów.

Ostrzeżenie zniknęło.


3
2017-10-02 13:51





Możesz wykluczyć słoik, którego nie chcesz (te, które podają duplikaty ostrzeżeń, używając następujących znaczników pod wtyczką cienia -

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

Więcej informacji można znaleźć na stronie http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html 


1
2017-12-03 17:53





Masz zależności w swoim pom, które zawierają zduplikowane klasy, ale bez odpowiedniego pom nie mogłem powiedzieć ani słowa na ten temat.


0
2018-03-21 11:58



dodał więcej informacji, czy możesz go jeszcze raz obejrzeć? Dzięki - Shengjie
Czy sprawdziłeś, która z zależności zawiera zduplikowane klasy? Na podstawie twoich danych wyjściowych jest commons-logginging-api-1.0.4.jar, który wydawał się pochodzić z innej wersji api (zduplikowanej) lub używasz innego dostawcy rejestrowania (slf4j?). - khmarbaise


Widziałem to w czasie zaćmienia, kiedy zaktualizowałem zależności mojego projektu nadrzędnego.

Usunąłem wszystkie pliki z mojego katalogu docelowego i naprawiłem problemy.


0
2017-12-09 21:43





Wszystkie powyższe (dotyczące sprawdzania drzewa zależności i wykluczania) są poprawne w większości przypadków, ale w moim przypadku (nie miałem nakładających się w moich zależnościach) cleanpomógł (nie wiem dlaczego):

mvn czysty package


0
2018-03-06 14:38





W moim przypadku polegałem na pakiecie, który tworzy także zacieniony słoik.

Zacienione słoiki są przeznaczone do wdrożenia, a nie jako zależność.

Stworzenie zmniejszonej zależności POM podczas procesu budowania zależności, instruuje specjalistę, na którym zależności można pominąć.

W konfiguracji maven-shade-plugin:

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

Aby uzyskać więcej informacji, zobacz ten post:

Do czego służy ta wtyczka maven-shade i dlaczego chciałbyś przenieść pakiety java?

Błąd, który otrzymałem od maven:

OSTRZEŻENIE: x.jar, y.jar zawierają zachodzące na siebie klasy


0
2018-02-07 02:13