Document that spring-boot:repackage should not be run from the command-line

[jmaasing]

This is exactly the same as reported #19055

Environment:

mvn -V
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
¨Java version: 14.0.1, vendor: Azul Systems, Inc.,
Default locale: en_SE, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.5", arch: "x86_64", family: "mac"

How to reproduce

Go to https://start.spring.io/
Select Maven, Java, 2.3.1, Jar, Java 14.
Unpack the downloaded zip file and go into the directory:
Type:
mvn clean package

wait for it to finish, then type:
mvn spring-boot:repackage

I get the following error:

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.3.1.RELEASE:repackage (default-cli) on project demo: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:2.3.1.RELEASE:repackage failed: Source file must not be null -> [Help 1]

Workaround

Run mvn clean package spring-boot:repackage

[wilkinsona]

Thank you, @jmaasing. Sorry, I see now that this is indeed exactly the same as #19055. I misread things earlier. We have precise steps to reproduce the problem now though (thank you for that) so let's keep this one open as we're better-placed to investigate.

[wilkinsona]

@jmaasing As @snicoll asked the raiser of #19055 can you please help us to understand your use case for calling the spring-boot:repackage goal in isolation rather than relying upon it being bound to the package phase?

[jmaasing]

For my use case I can bind it to the package phase if needed. The way I ended up testing this is because I have a parent-POM that builds not only the spring boot application but also other things and wanted to add the re-packaging as a separate step in the build pipeline.

I could not find anything in the documentation indicating that this goal can not be run separately. Neither when I do mvn spring-boot:help or on https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/html/#using

So maybe it's just a case of improving documentation that this goal can not be run from the command line unless you also do package.

[snicoll]

This is another occurrence of relying on attached artifacts with a forked lifecycle. We've recently fixed that for the build-image goal in #26721 and we should be able to apply a similar trick here.

[snicoll]

OK so I am taking that back. This goal does not fork the lifecycle and should therefore be used when package has ran. The example you shared above is the case of package running previously (in a completely different invocation) and we would rely on the content of target/ to do the right thing. I'd argue that it's a little odd of doing this.

I think this is particularly misleading when you run the goal and you expect repackage to update the state of the project to whatever changes happened since the last time you ran it, but it won't. So from that perspective, I think we should document that it shouldn't be used on the command line, unless package is executed as well.