Spring-boot: Cannot run repackage twice with different settings

[wouterv]

Since the release of 2.1.0.RELEASE, we get the following issue in our build:

build 31-Oct-2018 15:08:38 [ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.1.0.RELEASE:repackage (build-repackaged-jar) on project application: Execution build-repackaged-jar of goal org.springframework.boot:spring-boot-maven-plugin:2.1.0.RELEASE:repackage failed: Source must refer to an existing file, got /atlassian/bamboo/agent/5.15.3/xml-data/build-dir/BC-BGS-JOB1/repo/application/target/gear-exec-linux.jar.original -> [Help 1]

We fixed the plugin version to 2.0.6.RELEASE and all works fine again.

This is our specific part in the pom, the special thing about is that it creates two artifacts:

 <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.0.6.RELEASE</version> <!-- remove this and it will fail -->
    <executions>
        <execution>
            <id>build-linux-executable</id>
            <goals>
                <goal>repackage</goal>
            </goals>
            <configuration>
                <classifier>exec-linux</classifier>
                <executable>true</executable>
                <attach>false</attach>
            </configuration>
        </execution>    
        <execution>
            <id>build-repackaged-jar</id>
            <goals>
                <goal>repackage</goal>
            </goals>
            <configuration>
                <executable>false</executable>
                <attach>true</attach>
            </configuration>
        </execution>
    </executions>
</plugin>

[wilkinsona]

Thanks for the pom snippet, but I've been unable to reproduce the problem with it. As far as I can tell, the Maven plugins from 2.0.6 and 2.1.0 behave in the same way with that configuration. I have been testing with Maven 3.5.4. If you'd like us to spend some more time on this, can you please spend the time to produce a complete, minimal example that reproduces the behaviour you have described.

[snicoll]

@wouterv I am not 100% sure but this looks related to #14210 . Can you please double check? I've also updated the release notes to mention the new repackage execution id.

[wouterv]

@snicoll I tried with the execution id specific for the "main" artifact (the one without the classifier), but that did not help.

What did help however is changing the order to the following and now it works:

            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>build-repackage-executable</id>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                        <configuration>
                            <executable>false</executable>
                            <attach>true</attach>
                        </configuration>
                    </execution>
                    <execution>
                        <id>build-linux-executable</id>
                        <goals>
                            <goal>repackage</goal>
                        </goals>
                        <configuration>
                            <classifier>exec-linux</classifier>
                            <executable>true</executable>
                            <attach>false</attach>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

I'll leave the qualification of this to be a bug or a feature up to you ;-)

[snicoll]

@wouterv can you please attach a small sample that reproduces the problem? We can't really qualify something we can't reproduce. Thanks

[wouterv]

Sorry, it wasn't fixed by the thing I posted, but I created a sample demo by which you can test the change of behavior by just changing the plugin version.
demo.zip

[wilkinsona]

Thanks for the sample, but that doesn't appear to reproduce the failure you have described. I've tried with both Maven 3.3.9 and 3.5.4. In each case the output is similar to the following:

$ mvn -DskipTests install
[INFO] Scanning for projects...
[INFO] 
[INFO] --------------------------< com.example:demo >--------------------------
[INFO] Building demo 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:resources (default-resources) @ demo ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 0 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.7.0:compile (default-compile) @ demo ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:3.0.2:testResources (default-testResources) @ demo ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/awilkinson/Downloads/demo-7/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ demo ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.21.0:test (default-test) @ demo ---
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-jar-plugin:3.0.2:jar (default-jar) @ demo ---
[INFO] Building jar: /Users/awilkinson/Downloads/demo-7/target/gear.jar
[INFO] 
[INFO] --- spring-boot-maven-plugin:2.1.0.RELEASE:repackage (default) @ demo ---
[INFO] 
[INFO] --- spring-boot-maven-plugin:2.1.0.RELEASE:repackage (build-linux-executable) @ demo ---
[INFO] 
[INFO] --- spring-boot-maven-plugin:2.1.0.RELEASE:repackage (build-repackage-executable) @ demo ---
[INFO] Replacing main artifact /Users/awilkinson/Downloads/demo-7/target/gear.jar
[INFO] 
[INFO] --- build-helper-maven-plugin:1.7:attach-artifact (attach-artifacts) @ demo ---
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ demo ---
[INFO] Installing /Users/awilkinson/Downloads/demo-7/target/gear.jar to /Users/awilkinson/.m2/repository/com/example/demo/0.0.1-SNAPSHOT/demo-0.0.1-SNAPSHOT.jar
[INFO] Installing /Users/awilkinson/Downloads/demo-7/pom.xml to /Users/awilkinson/.m2/repository/com/example/demo/0.0.1-SNAPSHOT/demo-0.0.1-SNAPSHOT.pom
[INFO] Installing /Users/awilkinson/Downloads/demo-7/target/gear-exec-linux.jar to /Users/awilkinson/.m2/repository/com/example/demo/0.0.1-SNAPSHOT/demo-0.0.1-SNAPSHOT-exec-linux.sh
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.450 s
[INFO] Finished at: 2018-11-01T09:55:17Z
[INFO] ------------------------------------------------------------------------

[wouterv]

Ah, sorry forgot one vital piece.

run with:
mvn -DskipTests clean package install

Our actual command looks a bit different, but this is the consise one that kills it for us.

[wilkinsona]

Thanks. I can reproduce the problem now with Maven 3.5.4.

[snicoll]

This project is crazy complex and I am not sure where that regression comes from but it's a collection of different things:

• build-helper-maven-plugin runs before the repackage does so it's attaching an artifact that does not exist yet
• The Repackage goal is now able to replace an existing classified artifact rather than always repackaging the main artifact (see #11061). When it runs, there is an attached artifact with that classifier (see previous step) so it's being used (but that very goal is supposed to create it).

Having said that, the target repackaged jar isn't created because the source is already repackaged and there is a check in the repackager to just ignore that case irrespective of the configuration.

[snicoll]

I can make this project fail easy with Spring Boot 2.0.x as well:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>build-linux-executable</id>
            <goals>
                <goal>repackage</goal>
            </goals>
            <configuration>
                <classifier>exec-linux</classifier>
                <executable>true</executable>
                <attach>false</attach>
            </configuration>
        </execution>  
        <execution>
            <id>default</id>
            <configuration>
                <executable>false</executable>
                <attach>true</attach>
            </configuration>
        </execution>
    </executions>
</plugin>

(default is the id of the repackage execution in the parent, renamed to repackageas of Spring Boot 2.1).

[snicoll]

@wouterv can you please share why you're running mvn with clean package install? install will run package first so I can't see any benefit but only downsides (some plugins are executed twice for no good reason).

[snicoll]

@wouterv I've improved the plugin so that it is more lenient. I encourage you regardless to stop invoking maven with "package install" as it will run the same plugins twice in the lifecycle and I couldn't find any good reason to do that.