Description
July 7 2021 Original Request, BOOT-INF/classes requirement
We have encountered a Maven plugin internally that works by extracting .class files from a couple of special jar files into the executable jar in the BOOT-INF/classes directory. If those jars are instead put in BOOT-INF/lib there are class not found errors.
This sounds like the Spring Boot loader uses a child classloader for the BOOT-INF/lib jars, perhaps to ensure BOOT-INF/classes always win? Something in the parent classloader is trying to load these special classes and fails if loaded by the child classloader?
Jan 17 2024 Secondary Request, root requirement
We just added the ability to override the Spring Boot launcher (as #177) in the 2.3.1 release. The boot_launcher_class was added for this purpose. We now realize that the feature assumes the loader class is available in the root path of the jar (org/springframework/boot/loader/JarLauncher.class). For the standard Spring Boot launchers, this is fine.
By coincidence, within a day of having this new feature we found an internal Maven app that is doing custom steps in Maven to configure a custom written Spring Boot launcher. We are trying to migrate it to Bazel, but we need both boot_launcher_class (done) and also the ability to write the class in the root of the jar.
Definition of Done
- verify the classloader behaviors. Here is some sample code, try putting this in BOOT-INF/lib, BOOT-INF/classes, and root to see if they are using different classloaders: https://www.tutorialspoint.com/java/lang/class_getclassloader.htm
- create new attributes that accept deps, that in the packaging script explodes each jar into BOOT-INF/classes or root. These are special jars, so we don't need to support any fancy stuff like deps_exclude
springboot(
...
# BOOT-INF/libs
deps = [ ... ]
# BOOT-INF/classes
deps_as_classes = [...]
# /
deps_as_root = [...]
)