2014-09-15 16 views
9

Ho lavorato con varie ricette per produrre un file JAR eseguibile per un progetto JavaFX utilizzando un Maven POM. Ciascuna di queste domande StackOverflow descrive lo stesso problema. È frustrante che sembra che ci siano diverse soluzioni per lo stesso obiettivo.Firma JAR valida per i progetti JavaFX

problema:

java.lang.SecurityException: file di firma non valido digerire per Manifest attributi principali

errore durante l'esecuzione di un file JAR sulla riga di comando. Sebbene Netbeans possa eseguire felicemente il programma ed eseguire il debug del programma.

diagnosi

Ci sono diversi StackOverflow e forum domande su questo (i più utili di seguito). Anche se è un problema noto, devo ancora trovare una soluzione chiara per lavorare con JavaFX. Le procedure descritte in queste risposte non lo fanno con lo strumentoJavaFxPackager utilizzato per impacchettare-up il JAR JavaFX:

consueto approccio: La risposta palo popolare per questa domanda (255 voti al momento della scrittura): lavora con non moduli -JavaFX nel nostro progetto:

Tuttavia, quando inseriamo lo stesso plug-in nel POM che genera il file JAR JavaFX, abbiamo non è possibile ottenere: "Digest file di firma non valido ...". Nello specifico, ho inserito lo <artifactId>maven-shade-plugin</artifactId> prima e dopo la regola exec di JavaFxPackager. Il risultato è

  • Maven dà la: "file di firma non valido digerire per gli attributi principali Manifest ..." errore

** domanda *:

Come si riescono a confezionare un'applicazione JavaFX.Questo è il POM <build> section Netbeans imposta-up per JavaFX:

 <build> 
      <resources> 
      <resource> 
       <directory>src/main/resources</directory> 
       <filtering>true</filtering> 
      </resource> 
      </resources> 

      <plugins> 
      <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-dependency-plugin</artifactId> 
        <version>2.8</version> 
        <executions> 
         <execution> 
          <id>unpack-dependencies</id> 
          <phase>package</phase> 
          <goals> 
           <goal>unpack-dependencies</goal> 
          </goals> 
          <configuration> 
           <excludeScope>system</excludeScope> 
           <excludeGroupIds>junit,org.mockito,org.hamcrest</excludeGroupIds> 
           <outputDirectory>${project.build.directory}/classes</outputDirectory> 
          </configuration> 
         </execution> 
        </executions> 
       </plugin> 

       <plugin> 
        <groupId>org.codehaus.mojo</groupId> 
        <artifactId>exec-maven-plugin</artifactId> 
        <version>1.3.2</version> 
        <executions> 
         <execution> 
          <id>unpack-dependencies</id> 
          <phase>package</phase> 
          <goals> 
           <goal>exec</goal> 
          </goals> 
          <configuration> 
           <executable>${java.home}/../bin/javafxpackager</executable> 
           <arguments> 
            <argument>-createjar</argument> 
            <argument>-nocss2bin</argument> 
            <argument>-appclass</argument> 
            <argument>${mainClass}</argument> 
            <argument>-srcdir</argument> 
            <argument>${project.build.directory}/classes</argument> 
            <argument>-outdir</argument> 
            <argument>${project.build.directory}</argument> 
            <argument>-outfile</argument> 
            <argument>${project.build.finalName}.jar</argument> 
           </arguments> 
          </configuration> 
         </execution> 
         <execution> 
          <id>default-cli</id> 
          <goals> 
           <goal>exec</goal> 
          </goals> 
          <configuration> 
           <executable>${java.home}/bin/java</executable> 
           <commandlineArgs>${runfx.args}</commandlineArgs> 
          </configuration> 
         </execution> 
        </executions> 
       </plugin> 

       <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-compiler-plugin</artifactId> 
        <version>3.1</version> 
        <configuration> 
         <source>1.8</source> 
         <target>1.8</target> 
         <compilerArgument>-Xlint:unchecked</compilerArgument> <!-- all --> 
         <showWarnings>true</showWarnings> 
         <showDeprecation>true</showDeprecation> 
         <compilerArguments> 
          <bootclasspath>${sun.boot.class.path}${path.separator}${java.home}/lib  /jfxrt.jar</bootclasspath> 
         </compilerArguments> 
        </configuration> 
       </plugin> 

       <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-surefire-plugin</artifactId> 
        <version>2.16</version> 
        <configuration> 
         <additionalClasspathElements> 
          <additionalClasspathElement>${java.home}/lib/jfxrt.jar</additionalClasspathElement> 
         </additionalClasspathElements> 
        </configuration> 
       </plugin> 
      </plugins> 
     </build> 

La configurazione shard plugin utilizzato in base alla risposta in: "Invalid signature file" when attempting to run a .jar attualmente appare così:

   <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-shade-plugin</artifactId> 
         <!-- http://maven.apache.org/plugins/maven-shade-plugin/  --> 
         <!-- http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin --> 
         <!-- http://zhentao-li.blogspot.com.au/2012/06/maven-shade-plugin-invalid-signature.html  --> 
        <version>2.3</version> 
        <executions> 
         <execution> 
         <id>remove-sign-files</id> 
         <phase>package</phase> 
         <goals> 
          <goal>shade</goal> 
         </goals> 
         <configuration> 
          <filters> 
           <filter> 
            <artifact>*:*</artifact> 
            <excludes> 
             <exclude>classes/META-INF/*.SF</exclude> 
             <exclude>classes/META-INF/*.DSA</exclude> 
             <exclude>classes/META-INF/*.RSA</exclude> 
            </excludes> 
           </filter> 
          </filters> 
         </configuration> 
         </execution> 
        </executions> 
       </plugin> 

Per mantenere Netbeans fuori dall'equazione come per quanto possibile, ho appena eseguito

  • pacchetto mvn

Sulla riga di comando. Questo solo problema sembra essere un problema frequente e spero che qualcuno abbia decifrato il codice per il bundle JavFX in altri file JAR per un build JavaFX.

Altri link:

+0

http://stackoverflow.com/questions/34738653/maven-shade-plugin-does-not-exclude-the-manifest-signature-files – ycnix

risposta

1

Dopo molte ricerche ho trovato una soluzione che funziona per il mio progetto utilizzando JavaFX , Maven e NetBeans.

Sto lavorando a un semplice client REST che utilizza jersey e moxy per decodificare JSON. Dopo aver aggiunto la dipendenza, l'applicazione jersey-media-moxy segnala l'errore della firma non valida.

ho scoperto che questo dipende dalla presenza del file di firma ECLIPSE_.RSA e ECLIPSE_.SF all'interno del META-INF per alcune librerie. Nel mio caso sono stati i org.eclipse.persistence.moxy-2.5.0.jar, org.eclipse.persistence.antlr-2.5.0.jar, org.eclipse.persistence.asm-2.5.0.jar e org.eclipse.persistence.core-2.5.0.jar

Il pom.xml in Netbeans che ha indicato in esecuzione in due fasi separati. Il primo richiama il plugin maven-dependency che espande tutto il jar esterno. Il secondo uso exec-maven-plugin che chiama javafxpackager per creare il file jar finale e infine eseguirlo.

Effettuando i due passaggi in sequenza, la firma nelle librerie org.eclipse viene inserita nel META-INF del file jar finale e questo genera l'errore sulla firma.

La mia soluzione è aggiungere un passaggio intermedio tra l'esecuzione del plugin maven-dependency ed exec-maven-plugin. In questa fase ho intenzione di eliminare tutti i file di firma all'interno della directory

${project.build.directory}/classes 

Per fare questo ho usato un plugin di Maven-antrun-plugin

<plugin> 
    <artifactId>maven-antrun-plugin</artifactId> 
    <version>1.8</version> 
    <executions> 
     <execution> 
       <phase>package</phase> 
       <goals> 
        <goal>run</goal> 
       </goals> 
       <configuration> 
        <target> 
         <delete> 
          <fileset dir="${project.build.directory}/classes" includes="**/META-INF/*.DSA"/> 
          <fileset dir="${project.build.directory}/classes" includes="**/META-INF/*.RSA"/> 
          <fileset dir="${project.build.directory}/classes" includes="**/META-INF/*.SF"/> 
        </delete> 
       </target> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 
12

Ho avuto un problema molto simile; quando ho incluso un JAR firmato (bouncycastle) nel progetto.La sua firma è stato riconfezionato testualmente, con un conseguente ovvio SecurityException:

java.lang.SecurityException: file di firma non valido digerire per Manifest attributi principali

filtraggio di tutti i tipi fallito; la soluzione che funziona per me assomiglia a questo nel pom.xml:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-dependency-plugin</artifactId> 
    <version>2.8</version> 
    <executions> 
    <execution> 
     <id>unpack-dependencies</id> 
     <phase>package</phase> 
     <goals> 
     <goal>unpack-dependencies</goal> 
     </goals> 
     <configuration> 
     <excludes>META-INF/*.SF,META-INF/*.DSA,META-INF/*.RSA</excludes> 
     ... 
     </configuration> 
    </execution> 
    </executions> 
</plugin> 

ho omesse alcune righe dopo quello nuovo con il modello "esclude". Questa singola linea era la soluzione per me - includo le altre linee in modo da poter vedere il posizionamento. (Ho avuto problemi con molti altri post che hanno omesso il contesto di un tag, quindi cerco di salvare altri questo problema).

Speranza che aiuti gli altri con lo stesso problema.

+0

Finalmente! Ho sofferto per ore con il plugin de shade inutilmente. –

+0

Conosco il sentimento - mi ha motivato a scrivere questa risposta. – foo

+0

Questa dovrebbe essere la risposta corretta, controllo verde! – etlds