Manually attach main artifact if built by maven-assembly-plugin

Question

I am having problems building a maven project. I have a requirement to produce deterministic jar files, which must be binary-consistent across different builds and vers

Answer 1

In case you don't have a plugin to create and attach main artifact for you, there is a more generic solution with Groovy Maven plugin:

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>groovy-maven-plugin</artifactId>
    <version>2.1</version>
    <executions>
        <execution>
            <id>set-main-artifact</id>
            <phase>package</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    project.artifact.setFile(new File(project.build.directory, project.build.finalName + ".zip"))
                </source>
            </configuration>
        </execution>
    </executions>
</plugin>

Inspired by post https://stackoverflow.com/a/31513690/2053580 many thanks to https://stackoverflow.com/users/1314907/lukasz-guminski

Answer 2

After some more trial and failures I happened to come with a working solution. I am posting it here with the hopes to either be useful, or to have any issues with pointed to me, as I am not really confident if this is a reliable approach.

So, the error I received

An attached artifact must have a different ID than its corresponding main artifact.

meant to me that I cannot manually install "again" the main artifact. Since that artifact is not produced anymore by the maven-jar-plugin, it never gets scheduled for installation even if the file is present (the antrun copy task produces a jar with the same name).

Surprisingly, it needed a few little tricks to make this work again:

1. Re-enabled the maven-jar-plugin as it should be:

   <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-jar-plugin</artifactId>
     <version>2.5</version>
     <executions>
       <execution>
         <id>default-jar</id>
         <phase>package</phase>
       </execution>
     </executions>
   </plugin>
   

   This will produce the standard jar on the package phase, and most importantly, makes maven aware for it to be installed during the install phase.

2. Tweak the maven-antrun-plugin copy tasks to overwrite the already produced jar with the deterministic zip. The setup is nearly identical as in my question, so I am only adding the differences:

   <plugin>
     <artifactId>maven-antrun-plugin</artifactId>
     <version>1.7</version>
     <executions>
       <execution>...</execution>
       <execution>
         <id>step-3-rename-assembly-and-sources</id>
         <phase>package</phase>
         <configuration>
           <target>
             <copy file="${project.build.directory}/${project.build.finalName}-deterministic.zip"
                   tofile="${project.build.directory}/${project.build.finalName}.jar"
                   overwrite="true"/>
           </target>
         </configuration>
       </execution>
         . . .
     </executions>
   </plugin>
   

   The copy operation now has overwrite="true" specified. Originally, the copy operation seemed to ignore files in the destination if they already exist, and what happened is that the maven-jar-plugin had already produced the default jar artifact when the copying occured. With this option set, the maven-antrun-plugin now overrides the former jar with the deterministic one, and the latter becomes a subject of the maven install phase.

3. Removed the setup from the build-helper-maven-plugin, so that the main jar artifact is not copied a second time:

            <artifact>
              <file>${project.build.directory}/${project.build.finalName}.jar</file>
              <type>jar</type>
            </artifact>

That's it, the correct jar is installed in the .m2 dir.