Come registrare un file jar personalizzato come artefatto principale di Maven?

Question

Ho un progetto prevede di fornire un file jar:

<packaging>jar</packaging> 

ma il vaso è costruito in modo personalizzato, in modo che il confezionamento di default fatto con il vaso: vaso è stato disabilitato

<plugin> 
    <artifactId>maven-jar-plugin</artifactId> 
    <version>2.3.2</version> 
    <executions> 
    <execution> 
     <id>default-jar</id> 
     <phase>none</phase> 
    </execution> 
    </executions> 
</plugin> 

ma quindi quando voglio applicare l'ombra: ombreggiatura sul vaso esistente, viene visualizzato un errore

L'artefatto principale del progetto non esiste.

Presumo che Maven non conosce il file .jar creato da mio strumento personalizzato. Come farle sapere, perché antrun attachArtifact non funziona

<attachartifact file="./bin/classes.jar" classifier="" type="jar"/> 

l'errore che ottengo è

una formica BuildException è verificato: org.apache.maven.artifact.InvalidArtifactRTException: Per artefatto {: jar}: un artefatto allegato deve avere un ID diverso rispetto al suo artefatto principale corrispondente.

Quindi questo non è il metodo per registrare l'artefatto principale ... C'è qualche (senza scrivere un plugin java personalizzato)?

Grazie, Lukasz

Answer 1

Ho controllato le sorgenti di JarMojo e mi ha dato un'idea di come risolverlo con Groovy (via gmaven)

<plugin> 
    <groupId>org.codehaus.gmaven</groupId> 
    <artifactId>gmaven-plugin</artifactId> 
    <version>1.3</version> 
    <executions> 
    <execution> 
     <id>set-main-artifact</id> 
     <phase>package</phase> 
     <goals> 
     <goal>execute</goal> 
     </goals> 
     <configuration> 
     <source> 
      project.artifact.setFile(new File("./bin/classes.jar")) 
     </source> 
     </configuration> 
    </execution> 
    </executions> 
</plugin> 

e funziona! :)

Answer 2

Abbiamo visto lo stesso problema, con ottenere il "manufatto allegato deve avere un ID diverso rispetto al suo corrispondente principale manufatto" errore. Abbiamo trovato la soluzione nel seguente post del blog eccellente:

http://devblog.virtage.com/2013/04/embed-and-run-ant-tasks-and-scripts-from-maven/

Come dettagliato in this section, è possibile risolvere il problema con l'aggiunta di un classificatore in modo Maven può distinguere tra il vaso ant-costruito e il vaso Maven-costruito. Dal momento che si sta utilizzando antrun attachartifact, avresti bisogno di questo:

<attachartifact file="./bin/classes.jar" classifier="foo" type="jar"/> 

Nota avrete anche bisogno di includere tale classificatore (insieme a groupId, artifactId e versione) ogni volta che si vuole prendere questo barattolo come dipendenza in altri progetti.

Answer 3

Qualcosa di simile

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>build-helper-maven-plugin</artifactId> 
    <version>1.8</version> 
    <executions> 
     <execution> 
      <id>attach-artifacts</id> 
      <phase>package</phase> 
      <goals> 
       <goal>attach-artifact</goal> 
      </goals> 
      <configuration> 
       <artifacts> 
        <artifact> 
         <file>${basedir}/bin/classes.jar</file> 
         <type>jar</type> 
        </artifact> 
       </artifacts> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

Answer 4

Mentre la soluzione può funzionare per una build per l'installazione + fase o dove non ci sono dipendenze nel reattore, nei casi in cui unico edificio alla fase di compilazione o di test le classi non imballati non sarà trovato dalle dipendenze. La compilazione per la compilazione avviene quando si utilizzano plug-in come maven-release-plugin.

Estendere la soluzione prescelta per includere l'individuazione delle classi decompressi durante la compilazione

<plugin> 
    <groupId>org.codehaus.gmaven</groupId> 
    <artifactId>gmaven-plugin</artifactId> 
    <version>1.3</version> 
    <executions> 
    <execution> 
     <id>set-main-artifact-compile</id> 
     <phase>compile</phase> 
     <goals> 
     <goal>execute</goal> 
     </goals> 
     <configuration> 
     <source> 
      project.artifact.setFile(new File("./bin/classes")) 
     </source> 
     </configuration> 
    </execution> 
    <execution> 
     <id>set-main-artifact</id> 
     <phase>package</phase> 
     <goals> 
     <goal>execute</goal> 
     </goals> 
     <configuration> 
     <source> 
      project.artifact.setFile(new File("./bin/classes.jar")) 
     </source> 
     </configuration> 
    </execution> 
    </executions> 
</plugin> 

Di default l'esperto-install-plugin utilizzerà il manufatto individuato lungo le linee di ${project.build.directory}/${project.finalname}.jar

Così un'altra opzione potrebbe fare qualcosa del genere

<build> 
    <directory>bin</directory> 
    <outputDirectory>bin/classes</outputDirectory> 
    <finalName>classes</finalName> 
</build>