This is exactly the same as reported https://github.com/spring-projects/spring-boot/issues/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
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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.
Comment From: 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.