«Fichier de signature non valide» lors de la tentative d'exécution d'un .jar


450

Mon programme java est empaqueté dans un fichier jar et utilise une bibliothèque jar externe, château gonflable . Mon code se compile bien, mais l'exécution du bocal conduit à l'erreur suivante:

Exception dans le thread "principal" java.lang.SecurityException: résumé de fichier de signature non valide pour les attributs principaux du manifeste

J'ai googlé pendant plus d'une heure à la recherche d'une explication et trouvé très peu de valeur. Si quelqu'un a déjà vu cette erreur et pourrait offrir de l'aide, je serais obligé.


1
essayez-vous de signer votre propre pot? si oui, comment tentez-vous de le signer?
Cogsy

Non, au moins je ne pense pas. Xcode tente peut-être de le signer par lui-même, mais il ne semble pas y avoir de paramètre pour désactiver cette option.

n'oubliez pas de vérifier si les pots contenant des interfaces implémentées sont également signés!
gaurav

Réponses:


47

La solution répertoriée ici peut fournir un pointeur.

Résumé de fichier de signature non valide pour les attributs principaux du manifeste

Conclusion:

Il est probablement préférable de conserver le fichier jar officiel tel quel et de l'ajouter simplement en tant que dépendance dans le fichier manifeste de votre fichier jar d'application.


3
Comment pourrais-je refléter cela dans le fichier manifeste? Je n'en ai jamais édité un auparavant. J'utilise Xcode, et la convention courante est de mettre des bibliothèques de pots externes dans le répertoire myproject / lib pour inclusion, ce que je fais.

@ user123003 .. comme c'est le cas avec Intelli-J
MikeM

13
Malheureusement, certains d'entre nous utilisent des choses comme "plugin d'ombre maven", donc inclure des copies textuelles du pot original n'est pas aussi facile dans ces cas ...
rogerdpack

plug sans vergogne pour répondre sur ce site: stackoverflow.com/a/30922181/448779
foo

qu'en est-il du plugin maven-assembly-plugin? Il résout ce problème dans mon cas
jhenya-d

1083

Pour ceux qui ont obtenu cette erreur en essayant de créer un uber-jar avec maven-shade-plugin, la solution consiste à exclure les fichiers de signature manifeste en ajoutant les lignes suivantes à la configuration du plugin:

<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>

9
J'ai utilisé cette méthode pour mon uber-pot, et cela a très bien fonctionné. Il existe un exemple POM complet sur maven.apache.org/plugins/maven-shade-plugin/examples/… qui montre cette méthode filtrant les fichiers inclus.
M. Dudley

4
J'ai été tenté de lancer un tout nouveau fil de discussion - mais comme il s'agit du numéro 1 dans les résultats de Google - il semblait apte à le garder ici. Les lignes répertoriées ici se trouvent dans le fichier POM que j'utilise - et j'obtiens toujours l'erreur de sécurité lors de l'exécution de l'application. Il se construit bien - et bien sûr fonctionne bien quand NE PAS faire un pot Uber - comme prévu. Et bien que ce soit certainement une option - gardez-les séparés - cela ne résout pas le problème si vous voulez un pot Uber.
Gavin Baumanis

7
Cela fonctionne pour moi mais ... pourquoi avons-nous dû ignorer les fichiers de signature? Je suis sûr que le manifeste de signature est là pour une raison ....
Jeryl Cook

4
Assurez-vous de faire "mvn clean" après avoir fait ci-dessus!
codeinjuice

4
@JerylCook Les fichiers de signature sont là pour indiquer que le contenu de ce pot contient ces fichiers. Lorsque vous créez un pot uber, vous ajoutez un tas de fichiers supplémentaires au pot, et donc la signature n'est pas correcte. Si vous le vouliez vraiment, vous pourriez signer à nouveau le nouveau pot, mais bien sûr, ce serait avec votre signature, pas l'ancienne. Alternativement, vous ne pourriez pas distribuer le pot uber, mais plutôt inclure le pot signé dans un fichier séparé, mais cela irait à l'encontre du but d'un pot uber en premier lieu.
LadyCailin

139

Pour ceux qui utilisent gradle et essaient de créer et d'utiliser un gros pot, la syntaxe suivante pourrait aider.

jar {
    doFirst {
        from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } } 
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
}

1
Cela exclut simplement tous les fichiers avec des extensions .RSA, .SF ou .DSA dans le répertoire META-INF.
Keith P

9
La signature d'un fichier jar ajoute ces fichiers sous META-INF, mais lorsqu'ils sont inclus, les signatures ne correspondent plus au contenu du jar. Ainsi, leur suppression évite le décalage de signature.
Peter N. Steinmetz

1
Il y a une question similaire strictement sur l'utilisation du gros pot dans Gradle - stackoverflow.com/questions/4871656/…
Tomasz Sętkowski

3
Ça n'a pas marché pour moi. J'ai dû mettre le excludeà ma fatJartâche, qui avait cette configurations.compile.collectcommande. Voir stackoverflow.com/a/31426413/103412
Torsten

1
Cela résout également l'erreurError: Could not find or load main class App Caused by: java.lang.ClassNotFoundException: App
vonox7

57

Certaines de vos dépendances sont probablement des fichiers jar signés. Lorsque vous les combinez tous en un seul grand fichier jar, les fichiers de signature correspondants sont toujours présents et ne correspondent plus au fichier jar "grand combiné", de sorte que l'exécution s'arrête en pensant que le fichier jar a été falsifié (ce qu'il ... a donc pour parler).

Vous pouvez résoudre le problème en éliminant les fichiers de signature de vos dépendances jarfile. Malheureusement, il n'est pas possible de le faire en une seule étape .

Cependant, j'ai pu faire fonctionner cela avec Ant en deux étapes, sans nommer spécifiquement chaque dépendance de fichier jar, en utilisant:

<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>

L'élément sleep est censé empêcher les erreurs sur les fichiers avec des dates de modification à l'avenir .

D'autres variantes que j'ai trouvées dans les fils liés ne fonctionnaient pas pour moi.


Il est possible de le faire en une seule étape, en utilisant une manière différente pour spécifier vos fichiers JAR: <jar destfile = "build / myjar.jar"> <restrict> <not> <name name = "META-INF / *. SF" /> </not> <archives> <zips> <fileset dir = "jarfolder" includes = " * / .jar" /> </zips> </archives> </restrict> </jar>
DieterDP

57

Veuillez utiliser la commande suivante

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

4
Merci, j'ai eu ce problème avec intellij 14 et votre solution fonctionne pour moi!
Mohamad Kouhi Moghadam du

5
Merci, a travaillé pour moi dans Windows. Je viens d'ouvrir le pot avec 7zip, de supprimer les fichiers .SF. Je n'avais aucun fichier .RSA à supprimer
candino

3
Wow, puis-je simplement dire que cette solution était incroyable (et j'ai appris quelque chose de très puissant en cours de route!) Cela nécessite plus de votes positifs.
Dylan_Larkin

Je suis d'accord avec le commentaire de @Dylan_Larkin, c'est ce qui l'a résolu pour moi.
Felipe Valdes

26

J'ai rencontré ce problème lors de l'utilisation d'IntelliJ IDEA 14.01.

J'ai pu le réparer en:

Fichier-> Structure du projet-> Ajouter un nouveau (artefacts) -> jar-> À partir des modules avec des dépendances dans la fenêtre Créer un pot à partir du module:

Sélectionnez votre classe principale

Fichier JAR des bibliothèques Sélectionnez la copie dans le répertoire de sortie et liez via le manifeste


2
Est-il possible de mettre les pots dépendants dans le pot cible?
coder.chenzhi

vos solutions fonctionnent bien !! Merci beaucoup!
hzitoun

19

La sécurité est déjà un sujet difficile, mais je suis déçu de voir que la solution la plus populaire consiste à supprimer les signatures de sécurité. JCE requiert ces signatures . L'ombre Maven explose le fichier de pot BouncyCastle qui place les signatures dans META-INF, mais les signatures BouncyCastle ne sont pas valides pour un nouveau pot uber (uniquement pour le pot BC), et c'est ce qui provoque l'erreur de signature non valide dans ce fil .

Oui, l'exclusion ou la suppression des signatures comme suggéré par @ruhsuzbaykus fait en effet disparaître l'erreur d'origine, mais elle peut également conduire à de nouvelles erreurs cryptiques:

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

En spécifiant explicitement où trouver l'algorithme comme ceci:

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

J'ai pu obtenir une erreur différente:

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

JCE ne peut pas authentifier le fournisseur car nous avons supprimé les signatures cryptographiques en suivant la suggestion ailleurs dans ce même fil .

La solution que j'ai trouvée était le plugin packer exécutable qui utilise une approche jar-in-jar pour préserver la signature BouncyCastle dans un seul pot exécutable.

MISE À JOUR :

Une autre façon de le faire (la bonne façon?) Est d'utiliser le signataire Maven Jar . Cela vous permet de continuer à utiliser l'ombre Maven sans obtenir d'erreurs de sécurité. CEPENDANT, vous devez avoir un certificat de signature de code (Oracle suggère de rechercher "Certificat de signature de code Java"). La configuration POM ressemble à ceci:

<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>

Non, il n'y a aucun moyen pour que JCE reconnaisse un certificat auto-signé, donc si vous devez conserver les certificats BouncyCastle, vous devez soit utiliser le plugin jar-in-jar, soit obtenir un certificat JCE.


C'est certainement la bonne façon de le faire, même si cela demande beaucoup de travail. Merci d'avoir souligné, en détail, les mises en garde concernant l'utilisation de la réponse approuvée. Savez-vous si le certificat JCE doit être signé par Sun? Ou peut
WiteCastle

1
Il existe des tiers qui peuvent émettre des certificats de signature de code. Recherchez «Certificat de signature de code Java» pour voir les options.
MattW

Vous, monsieur, avez fait ma journée!
socona

A aidé pour moi. Il y a des fichiers dans cette bibliothèque, que je n'utilise pas, donc sauf qu'ils
m'aident

14

J'ai fait face au même problème, après référence quelque part, cela a fonctionné comme ci-dessous en changeant:

<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>

1
Cela a résolu mon problème rapidement! Pour être complet, cela devrait aller dans la maven-shade-pluginbalise.
Kuzeko

1
@Kuzeko Mise à jour de la réponse avec votre suggestion. Merci
m.nguyencntt

8

En supposant que vous construisez votre fichier jar avec ant, vous pouvez simplement demander à ant de laisser de côté le répertoire META-INF. Ceci est une version simplifiée de ma cible de fourmi:

<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>

où dois-je ajouter ces lignes?
Addi.Star

4

J'ai récemment commencé à utiliser IntelliJ sur mes projets. Cependant, certains de mes collègues utilisent toujours Eclipse sur les mêmes projets. Aujourd'hui, j'ai la même erreur après avoir exécuté le fichier jar créé par mon IntelliJ. Alors que toutes les solutions ici parlent de presque la même chose, aucune d'entre elles n'a fonctionné facilement pour moi (peut-être parce que je n'utilise pas ANT, maven build m'a donné d'autres erreurs qui m'ont renvoyé à http://cwiki.apache.org/ confluence / affichage / MAVEN / MojoExecutionException , et je n'ai pas pu comprendre par moi-même quels sont les pots signés!)

Enfin, cela m'a aidé

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

Devinez ce qui a été supprimé de mon fichier jar?!

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

Il semble que le problème concernait certains fichiers liés à l'éclipse.


4

J'ai eu le même problème gradlelors de la création d'un gros bocal, la mise à jour du build.gradlefichier avec une ligne d'exclusion a corrigé le problème.

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'
    }
}

1
Je déboguais depuis des jours, cela a résolu mon problème de gros pot.
sysuser

La façon dont j'ai débogué est de mettre le gros pot dans le répertoire lib de jmeter. Si vous avez le pot problématique dans lib / ext, ce problème ne sera pas évident, vous obtiendrez plutôt une erreur comme celle dans stackoverflow.com/questions/37624187/…
sysuser

1
exclure 'META-INF / *. RSA', 'META-INF / *. SF', 'META-INF / *. DSA' Cela manquait, un pot dépendant était à l'origine du problème
Nirbhay Mishra

3

Dans le cas où vous utilisez gradle, voici une tâche farJar complète:

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
}

2

Comparez le dossier META-INF dans le nouveau pot avec l'ancien pot (avant d'ajouter de nouvelles bibliothèques). Il est possible qu'il y ait de nouveaux fichiers. Si oui, vous pouvez les supprimer. Ça devrait aider. Cordialement, 999michal


2

Une stratégie consisterait à utiliser ANT pour simplifier la suppression de la signature de chaque fichier Jar. Il procéderait avec les étapes suivantes:

  1. Copie du MANIFEST.MF dans un fichier temporaire
  2. Suppression des entrées Nom et SHA du fichier temporaire
  3. Création d'un fichier Jar temporaire avec le manifeste temporaire
  4. Suppression du manifeste temporaire
  5. Échange du fichier Jar d'origine avec le fichier temporaire

Voici un macrodef ANT qui fait le travail:

<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>

"

La définition peut ensuite être appelée de cette façon dans une tâche ANT:

<target name="unsignJar">
    <unsignjar jarFile="org.test.myjartounsign.jar" />
</target>

2

Erreur: une erreur JNI s'est produite, veuillez vérifier votre installation et réessayer Exception dans le thread "main" java.lang.SecurityException: résumé de fichier de signature non valide pour les attributs principaux du manifeste à sun.security.util.SignatureFileVerifier.processImpl (SignatureFileVerifier.java: 314) sur sun.security.util.SignatureFileVerifier.process (SignatureFileVerifier.java:268) sur java.util.jar.JarVerifier.processEntry (JarVerifier.java:316) sur java.util.jar.JarVerifier.update (JarVerifier.java : 228) sur java.util.jar.JarFile.initializeVerifier (JarFile.java:383) sur java.util.jar.JarFile.getInputStream (JarFile.java:450) sur sun.misc.URLClassPath $ JarLoader $ 2.getInputStream (URLClassPath .java: 977) à sun.misc.Resource.cachedInputStream (Resource.java:77) à sun.misc.Resource.getByteBuffer (Resource.java:160) sur java.net.URLClassLoader.defineClass (URLClassLoader.java:454) sur java.net.URLClassLoader.access 100 $ (URLClassLoader.java:73) sur java.net.URLClassLoader $ 1.run (URLClassLoader.java:368) sur java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) sur java.security.AccessController.doPrivileged (Native Method) sur java.net.URLClassLoader.findClass (URLClassLoader.java:361) sur java.lang.ClassLoader.loadClass (ClassLoader.java:424) sur sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) sur java.lang.ClassLoader.loadClass (ClassLoader.java:357) sur sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper. java: 495)run (URLClassLoader.java:368) at java.net.URLClassLoader $ 1. run (URLClassLoader.java:362) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:361 ) à java.lang.ClassLoader.loadClass (ClassLoader.java:424) à sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) à java.lang.ClassLoader.loadClass (ClassLoader.java:357) au soleil .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)run (URLClassLoader.java:368) at java.net.URLClassLoader $ 1. run (URLClassLoader.java:362) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:361 ) à java.lang.ClassLoader.loadClass (ClassLoader.java:424) à sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) à java.lang.ClassLoader.loadClass (ClassLoader.java:357) au soleil .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) sur java.lang.ClassLoader.loadClass (ClassLoader.java:357) sur sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) sur java.lang.ClassLoader.loadClass (ClassLoader.java:357) sur sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)

Ce qui m'a aidé (IntelliJ IDEA 2016.3): Fichier -> Structure du projet -> Artefacts -> Ajouter JAR -> Sélectionner la classe principale -> Choisissez "copier dans le répertoire de sortie et lier via le manifeste" -> OK -> Appliquer -> Construire - > Construire des artefacts ... -> Construire



1

Si vous recherchez une solution Fat JAR sans déballer ni altérer les bibliothèques originales mais avec un chargeur de classe JAR spécial, jetez un œil à mon projet ici .

Avertissement: je n'ai pas écrit le code, il suffit de l'empaqueter et de le publier sur Maven Central et de décrire dans mon fichier Lisez-moi comment l'utiliser.

Je l'utilise personnellement pour créer des fichiers JAR uber exécutables contenant des dépendances BouncyCastle. Peut-être que cela vous est également utile.


0

Pour ceux qui ont des problèmes avec la solution acceptée, il existe une autre façon d'exclure des ressources du pot ombré avec 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>

Depuis Shade 3.0, ce transformateur accepte une liste de ressources. Avant cela, il vous suffit d'utiliser plusieurs transformateurs chacun avec une seule ressource.


0

Cela m'est arrivé dans Intellij lorsque j'ai cliqué sur "Ajouter en tant que projet Maven" sur la dernière ligne quand Intellij a dit "fichiers pom non gérés trouvés". Pendant ce temps, le dossier out a déjà été généré. Il n'a donc pas été modifié récemment.

La suppression du dossier et l'exécution du programme ont résolu le problème pour moi. le dossier a ensuite été recréé.

Voir aussi la réponse de Little Fox. L'erreur que j'ai reçue était très similaire à la sienne.


-1

J'avais un problème similaire. La raison en était que je compilais en utilisant un JDK avec un JRE différent de celui par défaut dans ma boîte Windows.

L'utilisation du java.exe correct a résolu mon problème.


-2

Si vous obtenez cela lorsque vous essayez de lier des fichiers JAR pour un projet de liaisons Xamarin.Android comme ceci:

JARTOXML: avertissement J2XA006: une erreur de classe manquante a été déclenchée lors de la réflexion de com.your.class: condensé de fichier de signature non valide pour les attributs principaux du manifeste

Ouvrez simplement les fichiers JAR à l'aide de Winzip et supprimez les répertoires meta-inf. Reconstruire - travail effectué


1
C'est une technique horrible. Absolument horrible. Effectuez les corrections localement sans apporter de modifications aux pots entrants
sinisterrook
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.