„Nieprawidłowy plik podpisu” podczas próby uruchomienia pliku .jar

450

Mój program Java jest spakowany w pliku jar i korzysta z zewnętrznej biblioteki jar, nadmuchiwany zamek . Mój kod kompiluje się poprawnie, ale uruchomienie jar prowadzi do następującego błędu:

Wyjątek w wątku „main” java.lang.SecurityException: Niepoprawne podsumowanie pliku sygnatury dla głównych atrybutów manifestu

Przez ponad godzinę szukałem wyjaśnień i znalazłem niewiele wartości. Gdyby ktoś widział ten błąd i mógł zaoferować pomoc, byłbym zobowiązany.

java jar executable-jar
źródło
1
próbujesz podpisać własny słoik? jeśli tak, to jak próbujesz to podpisać?
Cogsy,
Nie, przynajmniej tak mi się wydaje. Xcode może próbować podpisać go samodzielnie, ale wydaje się, że nie ma żadnych ustawień, aby to wyłączyć.
nie zapomnij sprawdzić, czy słoiki zawierające zaimplementowane interfejsy są również podpisane!
gaurav

Odpowiedzi:

47

Wymienione tutaj rozwiązanie może zapewnić wskaźnik.

Niepoprawne podsumowanie pliku sygnatury dla głównych atrybutów manifestu

Dolna linia:

Prawdopodobnie najlepiej jest zachować oficjalny plik jar bez zmian i dodać go jako zależność w pliku manifestu pliku jar aplikacji.

Nrj
źródło
3
Jak mam to odzwierciedlić w pliku manifestu? Nigdy wcześniej go nie edytowałem. Używam Xcode, a powszechną konwencją jest umieszczanie zewnętrznych bibliotek jar w katalogu myproject / lib w celu włączenia, co właśnie robię.
@ user123003 .. jak ma to miejsce w przypadku Intelli-J
MikeM
13
Niestety, niektórzy z nas używają takich rzeczy jak „plugin maven odcień”, więc w tym przypadku dosłowne kopie oryginalnego słoika nie są tak łatwe ...
rogerdpack
bezwstydna wtyczka do odpowiedzi na tej stronie: stackoverflow.com/a/30922181/448779
foo
co z wtyczką maven-assembly-plug?
Rozwiązuje
1082

Dla tych, którzy dostali ten błąd podczas próby utworzenia uber-słoik z maven-shade-plugin, rozwiązaniem jest wykluczenie oczywistych plików sygnatur dodając następujące wiersze do konfiguracji pluginu:

<configuration>
    <filters>
        <filter>
            <artifact>*:*</artifact>
            <excludes>
                <exclude>META-INF/*.SF</exclude>
                <exclude>META-INF/*.DSA</exclude>
                <exclude>META-INF/*.RSA</exclude>
            </excludes>
        </filter>
    </filters>
    <!-- Additional configuration. -->
</configuration>
ruhsuzbaykus
źródło
9
Użyłem tej metody do mojego słoika i zadziałało świetnie. Pełny przykład POM znajduje się na stronie maven.apache.org/plugins/maven-shade-plugin/examples/…, który pokazuje tę metodę filtrowania dołączonych plików.
M. Dudley,
4
Kusiło mnie, aby rozpocząć zupełnie nowy wątek - ale ponieważ jest to numer 1 w wynikach Googles - wydaje się, że warto go tutaj zachować. Wymienione tutaj wiersze znajdują się w pliku POM, którego używam - i nadal pojawia się błąd bezpieczeństwa podczas uruchamiania aplikacji. Kompiluje się dobrze - i oczywiście działa dobrze, gdy NIE robi słoika Ubera - zgodnie z oczekiwaniami. I chociaż z pewnością jest to opcja - trzymaj je oddzielnie - nie rozwiązuje problemu, jeśli chcesz Uber Jar.
Gavin Baumanis
7
To działa dla mnie, ale ... dlaczego musieliśmy zignorować pliki sygnatur? Jestem pewien, że manifest podpisu istnieje z jakiegoś powodu ...
Jeryl Cook
4
Pamiętaj, aby wykonać „mvn clean” po wykonaniu powyższej czynności!
codeinjuice
4
@JerylCook Pliki sygnatur wskazują, że zawartość tego jar zawiera te pliki. Kiedy tworzysz słoik Uber, dodajesz do niego słoik więcej plików, a zatem podpis jest niepoprawny. Jeśli naprawdę chcesz, możesz ponownie podpisać nowy słoik, ale oczywiście będzie to z twoim podpisem, a nie starym. Alternatywnie, nie można dystrybuować słoika Uber, ale zamiast tego dołączyć podpisany słoik jako osobny plik, ale wtedy to w ogóle podważa cel słoika Uber.
LadyCailin
139

Dla tych, którzy używają gradle i próbują utworzyć i użyć grubego słoika, pomocna może być następująca składnia.

jar {
    doFirst {
        from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } } 
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
}
Keith P.
źródło
1
To po prostu w zasadzie wyklucza wszystkie pliki z rozszerzeniami .RSA, .SF lub .DSA w katalogu META-INF.
Keith P,
9
Podpisanie pliku jar dodaje te pliki do META-INF, ale po ich uwzględnieniu podpisy nie są już zgodne z zawartością jar. W ten sposób ich usunięcie pozwala uniknąć niedopasowania podpisu.
Peter N. Steinmetz
1
Podobne pytanie dotyczy wyłącznie używania słoika z tłuszczem w gradle - stackoverflow.com/questions/4871656/...
Tomasz Sętkowski
3
To nie działało dla mnie. Musiałem excludewykonać swoje fatJarzadanie, które miało to configurations.compile.collectpolecenie. Zobacz stackoverflow.com/a/31426413/103412
Torsten
1
To rozwiązuje również błądError: Could not find or load main class App Caused by: java.lang.ClassNotFoundException: App
vonox7,
56

Niektóre z Twoich zależności są prawdopodobnie podpisanymi plikami jar. Kiedy połączysz je wszystkie w jeden duży plik jar, odpowiednie pliki sygnatur są nadal obecne i nie pasują już do „dużego połączonego” pliku jar, więc środowisko wykonawcze przestaje myśleć, że plik jar został sfałszowany (który ... musi to zrobić mówić).

Możesz rozwiązać problem, eliminując pliki sygnatur z zależności plików jar. Niestety nie można tego zrobić w jednym kroku .

Udało mi się to jednak uzyskać dzięki Antowi w dwóch krokach, bez konkretnej nazwy każdej zależności pliku jar, używając:

<target name="jar" depends="compile" description="Create one big jarfile.">
    <jar jarfile="${output.dir}/deps.jar">
        <zipgroupfileset dir="jars">
            <include name="**/*.jar" />
        </zipgroupfileset>
    </jar>
    <sleep seconds="1" />
    <jar jarfile="${output.dir}/myjar.jar" basedir="${classes.dir}">
        <zipfileset src="${output.dir}/deps.jar" excludes="META-INF/*.SF" />
        <manifest>
            <attribute name="Main-Class" value="com.mycompany.MyMain" />
        </manifest>
    </jar>
</target>

Element uśpienia ma zapobiegać błędom dotyczącym plików z datami modyfikacji w przyszłości .

Inne odmiany, które znalazłem w połączonych wątkach, nie działały dla mnie.

Rich Apodaca
źródło
Można to zrobić w jednym kroku, używając innego sposobu określania swoich słoików: <jar destfile = "build / myjar.jar"> <restrict> <not> <name name = "META-INF / *. SF" /> </not> <archives> <zips> <fileset dir = "jarfolder" zawiera = " * / .jar" /> </zips> </archives> </restrict> </jar>
DieterDP
56

Użyj następującego polecenia

zip -d yourjar.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'
Peter2711
źródło
4
Dziękuję, miałem ten problem z intellij 14 i twoje rozwiązanie działa dla mnie!
Mohamad Kouhi Moghadam
5
Dziękuję, pracowałeś dla mnie w systemie Windows. Właśnie otworzyłem słoik za pomocą 7zip, usunąłem pliki .SF. Nie miałem żadnych plików .RSA do usunięcia
candino
3
Wow, mogę po prostu powiedzieć, że to rozwiązanie było niesamowite (i nauczyłem się po drodze czegoś bardzo potężnego!) To wymaga więcej ulepszeń.
Dylan_Larkin
Zgadzam się z komentarzem @Dylan_Larkin, to właśnie dla mnie to rozwiązało.
Felipe Valdes
26

Miałem ten problem podczas korzystania z IntelliJ IDEA 14.01.

Byłem w stanie to naprawić:

Plik-> Struktura projektu-> Dodaj nowy (artefakty) -> jar-> Z modułów z zależnościami w oknie Utwórz jar z modułu:

Wybierz swoją główną klasę

Plik JAR z bibliotek Wybierz kopię do katalogu wyjściowego i połącz poprzez manifest

Travis
źródło
2
Czy można umieścić zależne słoiki w docelowym słoju?
coder.chenzhi
twoje rozwiązania działają dobrze !! Wielkie dzięki!
hzitoun
19

Bezpieczeństwo to już trudny temat, ale jestem rozczarowany, widząc, że najpopularniejszym rozwiązaniem jest usunięcie sygnatur bezpieczeństwa. JCE wymaga tych podpisów . Odcień Maven wybucha plik jar BouncyCastle, który umieszcza podpisy w META-INF, ale podpisy BouncyCastle nie są ważne dla nowego jar-uber-jar (tylko dla jar BC), i to powoduje błąd nieprawidłowego podpisu w tym wątku .

Tak, wykluczenie lub usunięcie podpisów zgodnie z sugestią @ruhsuzbaykus rzeczywiście powoduje zniknięcie pierwotnego błędu, ale może również prowadzić do nowych, tajemniczych błędów:

java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available

Określając wprost, gdzie znaleźć taki algorytm:

SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");

Byłem w stanie uzyskać inny błąd:

java.security.NoSuchProviderException: JCE cannot authenticate the provider BC

JCE nie może uwierzytelnić dostawcy, ponieważ usunęliśmy podpisy kryptograficzne , postępując zgodnie z sugestią w innym miejscu tego samego wątku .

Rozwiązaniem, które znalazłem, była wykonywalna wtyczka pakująca, która wykorzystuje podejście jar-in-jar do zachowania podpisu BouncyCastle w jednym, wykonywalnym jarie .

AKTUALIZACJA :

Innym sposobem na zrobienie tego (poprawny sposób?) Jest użycie sygnatariusza Jar Maven . Dzięki temu możesz nadal korzystać z cienia Maven bez błędów bezpieczeństwa. JEDNAK musisz mieć certyfikat do podpisywania kodu (Oracle sugeruje wyszukiwanie „Java Code Signing Certificate”). Konfiguracja POM wygląda następująco:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>org.bouncycastle:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>your.class.here</mainClass>
                    </transformer>
                </transformers>
                <shadedArtifactAttached>true</shadedArtifactAttached>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jarsigner-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <id>sign</id>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>/path/to/myKeystore</keystore>
        <alias>myfirstkey</alias>
        <storepass>111111</storepass>
        <keypass>111111</keypass>
    </configuration>
</plugin>

Nie, nie ma sposobu, aby JCE rozpoznała certyfikat z podpisem własnym, więc jeśli chcesz zachować certyfikaty BouncyCastle, musisz albo użyć wtyczki jar-in-jar, albo uzyskać certyfikat JCE.

MattW
źródło
To zdecydowanie właściwy sposób, aby to zrobić, nawet jeśli jest to pracochłonne. Dziękujemy za szczegółowe wskazanie zastrzeżeń dotyczących korzystania z zatwierdzonej odpowiedzi. Czy wiesz, czy certyfikat JCE musi zostać podpisany przez firmę Sun? Lub może
WiteCastle
1
Istnieją podmioty zewnętrzne, które mogą wydawać certyfikaty do podpisywania kodu. Wyszukaj „Certyfikat podpisywania kodu Java”, aby wyświetlić opcje.
MattW,
Pan, sprawił, że mój dzień!
socona
Pomógł mi. W tej bibliotece jest kilka plików, których nie używam, więc oprócz nich pomóżcie mi z plikiem fat-jar
Saidolim
14

Napotkałem ten sam problem, gdzieś po odwołaniu, działało jak poniżej:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.1</version>
    <configuration>
        <createDependencyReducedPom>false</createDependencyReducedPom>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>
m.nguyencntt
źródło
1
To szybko rozwiązało mój problem! Dla kompletności powinno to znaleźć się w maven-shade-plugintagu.
Kuzeko
1
@Kuzeko Zaktualizowałem anwser swoją sugestią. Dzięki
m.nguyencntt
8

Zakładając, że budujesz plik jar za pomocą mrówki, możesz po prostu poinstruować mrówkę, aby pominęła reżim META-INF. To jest uproszczona wersja mojego celu mrówek:

<jar destfile="app.jar" basedir="${classes.dir}">
    <zipfileset excludes="META-INF/**/*" src="${lib.dir}/bcprov-jdk16-145.jar"></zipfileset>
    <manifest>
        <attribute name="Main-Class" value="app.Main"/>
    </manifest>
</jar>
Kim Stebel
źródło
gdzie powinienem dodać te linie?
Addi.Star,
4

Ostatnio zacząłem używać IntelliJ w swoich projektach. Jednak niektórzy z moich kolegów nadal używają Eclipse w tych samych projektach. Dzisiaj mam ten sam błąd po uruchomieniu pliku jar utworzonego przez mój IntelliJ. Podczas gdy wszystkie rozwiązania tutaj mówiące o prawie tej samej rzeczy, żadne z nich nie działało dla mnie łatwo (być może dlatego, że nie używam ANT, build maven dał mi inne błędy, które odsyłały mnie do http://cwiki.apache.org/ confluence / display / MAVEN / MojoExecutionException , a także nie mogłem dowiedzieć się, jakie są podpisane słoiki!)

Wreszcie mi to pomogło

zip -d demoSampler.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'

Zgadnij, co zostało usunięte z mojego pliku jar ?!

deleting: META-INF/ECLIPSE_.SF 
deleting: META-INF/ECLIPSE_.RSA

Wygląda na to, że problem dotyczył niektórych plików związanych z zaćmieniem.

mhn_namak
źródło
4

Miałem ten sam problem gradlepodczas tworzenia grubego słoika, aktualizacja build.gradlepliku za pomocą linii wykluczenia rozwiązała problem.

jar {
    from {
        configurations.compile.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
    manifest {
        attributes 'Main-Class': 'com.test.Main'
    }
}
Ahmad Al-Kurdi
źródło
1
Debugowałem przez kilka dni, to rozwiązało mój problem ze słoikiem.
sysuser
Sposób, w jaki debugowałem, polega na umieszczeniu słoika tłuszczu w katalogu lib jmeter. Jeśli masz problematyczną słoik w lib / ext, ten problem nie będzie oczywisty, a raczej pojawi się błąd taki jak w stackoverflow.com/questions/37624187/...
sysuser
1
wyklucz „META-INF / *. RSA”, „META-INF / *. SF”, „META-INF / *. DSA” Tego brakowało, przyczyną był problem zależnego słoika
Nirbhay Mishra
3

Jeśli używasz gradle, oto pełne zadanie FarJar:

version = '1.0'
//create a single Jar with all dependencies
task fatJar(type: Jar) {
    manifest {
        attributes 'Implementation-Title': 'Gradle Jar File Example',  
            'Implementation-Version': version,
            'Main-Class': 'com.example.main'
    }
    baseName = project.name + '-all'
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
    with jar
}
Nick De Greek
źródło
2

Porównaj folder META-INF w nowym słoiku ze starym słojem (zanim dodasz nowe biblioteki). Możliwe, że pojawią się nowe pliki. Jeśli tak, możesz je usunąć. To powinno pomóc. Pozdrawiam, 999michal

999michal
źródło
2

Strategia polegałaby na użyciu ANT w celu uproszczenia usuwania podpisu z każdego pliku Jar. Wykonałby następujące kroki:

  1. Kopiowanie pliku MANIFEST.MF do pliku tymczasowego
  2. Usuwanie nazw i wpisów SHA z pliku tymczasowego
  3. Tworzenie tymczasowego pliku Jar z tymczasowym manifestem
  4. Usunięcie tymczasowego manifestu
  5. Zamiana oryginalnego pliku Jar na tymczasowy

Oto makrodef ANT wykonujący pracę:

<macrodef name="unsignjar" description="To unsign a specific Jar file">
    <attribute name="jarfile" 
        description="The jar file to unsign" />
    <sequential>
<!-- Copying to the temporary manifest file -->
        <copy toFile="@{jarFile}_MANIFEST.tmp">
            <resources>
                <zipentry zipfile="@{jarFile}" name="META-INF/MANIFEST.MF"/>
            </resources>
        </copy>
<!-- Removing the Name and SHA entries from the temporary file -->
        <replaceregexp file="@{jarFile}_MANIFEST.tmp" match="\nName:(.+?)\nSH" replace="SH" flags="gis" byline="false"/>
        <replaceregexp file="@{jarFile}_MANIFEST.tmp" match="SHA(.*)" replace="" flags="gis" byline="false"/>
<!-- Creating a temporary Jar file with the temporary manifest -->
        <jar jarfile="@{jarFile}.tmp"
            manifest="@{jarFile}_MANIFEST.tmp">
            <zipfileset src="@{jarFile}">
                <include name="**"/>
                <exclude name="META-INF/*.SF"/>
                <exclude name="META-INF/*.DSA"/>
                <exclude name="META-INF/*.RSA"/>
            </zipfileset>
        </jar>
<!-- Removing the temporary manifest -->
        <delete file="@{jarFile}_MANIFEST.tmp" />
<!-- Swapping the original Jar file with the temporary one -->
        <move file="@{jarFile}.tmp"
              tofile="@{jarFile}"
              overwrite="true" />
</sequential>

`

Definicja może być następnie wywołana w ten sposób w zadaniu ANT:

<target name="unsignJar">
    <unsignjar jarFile="org.test.myjartounsign.jar" />
</target>
bdulac
źródło
2

Błąd: Wystąpił błąd JNI, sprawdź instalację i spróbuj ponownie. Wyjątek w wątku „main” java.lang.SecurityException: Nieprawidłowe podsumowanie pliku sygnatury dla głównych atrybutów manifestu w sun.security.util.SignatureFileVerifier.processImpl (SignatureFileVerifier.java: 314) w sun.security.util.SignatureFileVerifier.process (SignatureFileVerifier.java:268) w java.util.jar.JarVerifier.processEntry (JarVerifier.java:316) w java.util.jar.JarVerifier.update (JarVerifier.java : 228) w java.util.jar.JarFile.initializeVerifier (JarFile.java:383) w java.util.jar.JarFile.getInputStream (JarFile.java:450) w sun.misc.URLClassPath $ JarLoader $ 2.getInputStream (URLClassPathStath .java: 977) w sun.misc.Resource.cachedInputStream (Resource.java:77) w sun.misc.Resource.getByteBuffer (Resource.java:160) w java.net.URLClassLoader.defineClass (URLClassLoader.java:454) w java.net.URLClassLoader.access 100 $ (URLClassLoader.java:73) w java.net.URLClassLoader $ 1.run (URLClassLoader.java:368) w java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) w java.security.AccessController.doPrivileged (Metoda rodzima) w java.net.URLClassLoader.findClass (URLClassLoader.java:361) w java.lang.ClassLoader.load (ClassLoader.java:424) w sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) w java.lang.ClassLoader.loadClass (ClassLoader.java:357) w sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper. java: 495)uruchom (URLClassLoader.java:368) w java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) w java.security.AccessController.doPrivileged (Metoda rodzima) w java.net.URLClassLoader.findClass (URLClassLoader.java:36 ) w java.lang.ClassLoader.loadClass (ClassLoader.java:424) w sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) w java.lang.ClassLoader.loadClass (ClassLoader.java:357) w słońcu .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)uruchom (URLClassLoader.java:368) w java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) w java.security.AccessController.doPrivileged (Metoda rodzima) w java.net.URLClassLoader.findClass (URLClassLoader.java:36 ) w java.lang.ClassLoader.loadClass (ClassLoader.java:424) w sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) w java.lang.ClassLoader.loadClass (ClassLoader.java:357) w słońcu .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) w java.lang.ClassLoader.loadClass (ClassLoader.java:357) w sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) w java.lang.ClassLoader.loadClass (ClassLoader.java:357) w sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)

Co mi pomogło (IntelliJ IDEA 2016.3): Plik -> Struktura projektu -> Artefakty -> Dodaj plik JAR -> Wybierz klasę główną -> Wybierz „skopiuj do katalogu wyjściowego i połącz przez manifest” -> OK -> Zastosuj -> Kompiluj - > Buduj artefakty ... -> Buduj

Mały Lis
źródło
1

Jeśli szukasz rozwiązania Fat JAR bez rozpakowywania lub manipulowania oryginalnymi bibliotekami, ale ze specjalnym modułem ładującym klasy JAR, spójrz na mój projekt tutaj .

Oświadczenie: Nie napisałem kodu, po prostu spakowałem go i opublikowałem w Maven Central i opisałem w moim read-me, jak go używać.

Osobiście używam go do tworzenia uruchamialnych plików JAR uber zawierających zależności BouncyCastle. Może to też jest przydatne dla ciebie.

kriegaex
źródło
0

Dla tych, którzy mają problemy z zaakceptowanym rozwiązaniem, istnieje inny sposób na wykluczenie zasobu z zacienionego słoika za pomocą DontIncludeResourceTransformer:

https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#DontIncludeResourceTransformer

          <transformers>
            <transformer implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer">
                <resource>BC1024KE.DSA</resource>
            </transformer>
          </transformers>

Od wersji 3.0 ten transformator akceptuje listę zasobów. Wcześniej wystarczy użyć wielu transformatorów, każdy z jednym zasobem.

M.Liang
źródło
0

Zdarzyło mi się to w Intellij, kiedy kliknąłem „Dodaj jako projekt Maven” w dolnej linii, kiedy Intellij powiedział „znaleziono niezarządzane pliki pom”. Tymczasem nasz folder został już wygenerowany. Więc nie otrzymałem ostatnich zmian.

Usunięcie folderu i uruchomienie programu rozwiązało problem. nasz folder został następnie ponownie utworzony.

Zobacz także odpowiedź Little Fox. Błąd, który otrzymałem, był bardzo podobny do jego.

Onat Korucu
źródło
-1

Miałem podobny problem. Powodem było to, że kompilowałem przy użyciu JDK z innym JRE niż domyślny w moim oknie Windows.

Korzystanie z prawidłowego pliku java.exe rozwiązało mój problem.

Jus12
źródło
-2

Jeśli otrzymujesz to podczas próby powiązania plików JAR dla projektu powiązań Xamarin.Android w następujący sposób:

JARTOXML: ostrzeżenie J2XA006: podniesiono błąd braku klasy podczas odzwierciedlania com.your.class: Niepoprawne podsumowanie pliku sygnatury dla głównych atrybutów manifestu

Wystarczy otworzyć pliki JAR za pomocą Winzip i usunąć katalogi meta-inf. Przebuduj - praca wykonana

Dean Wild
źródło
1
To okropna technika. Absolutnie okropne. Dokonuj poprawek lokalnie, nie wprowadzaj zmian w przychodzących słoikach
sinisterrook