Add RepackageModule to build assemblies based on Spring Boot tools
#4489
Conversation
|
This is an early draft for a This derives from The Spring-Boot tools are encapsulated into a separate Module to avoid multiple instance. A pre-setup version using the tools that were available at built-time is available as |
7003265 to
1d41d44
Compare
This derives from `JavaModule` for now. I tried to just derive from AssemblyModule or RunModule, but could get it right. Since we revisit the module structure anyways, I think this can be tried later again. The Spring-Boot tools are encampsulated into a separate Module to avoid multiple instance. A pre-setup version using the tools that were available at built-time is available as `ExternalModule` and used by default.
1d41d44 to
c34f430
Compare
|
@lefou I wonder if we should give |
Yeah, the name is quite long. And beside the tools coming under the Spring Boot brand, the utility is independent. We could name it |
|
Maybe we can all it |
|
That's assuming that this isn't hard-coded to be used for spring boot of course. If it does do stuff specific to spring-boot, we should just leave the name as it is |
|
The repackaging does not require the project to be a Spring project. The documentation is already in the |
2d8cdd6 to
48a6429
Compare
|
Reworked Module and updated PR description. |
RepackageModule to build assemblies based on Spring Boot tools
This adds a
mill.javalib.repackage.RepackageModulewhich enhances aModulewith arepackagedJartask to produce self-executable JAR files. If the module is aJavaModuleeverything should work out of the box. Otherwise, the use may need to override various tasks, which is analogue to usingRunModuleorAssemblyModule.The Spring-Boot tools are encapsulated into a separate
mill.javalib.spring.boot.SpringBootToolsModuleto avoid instantiating multiple instance. A pre-configured version using the tools version present at built-time is available asExternalModuleand used by default.Fix #4479