Multiple `springboot` targets in one package

[Zetten]

I've got an application which is targeting multiple deployment environments, and therefore we create multiple distributable Spring Boot jars for each service. These consist of our common application java_library with different runtime dependencies. For example, we bundle different Spring Cloud starters for Kubernetes and Netflix Eureka service discovery.

Right now I've got a fairly naive Spring Boot packaging rule (just invoking Repackager) but I'm aiming to migrate to the rules provided here in anticipation of better Docker layering.

So, assuming I want to create two springboot targets, myservice_k8s and myservice_standalone, there are a couple of problems:

• All the intermediate files are named according to the package, not the target.
• The springboot macro also wants to generate hardcoded identically-named files - MANIFEST.MF, git.properties and bazelrun_env.sh.

I've taken a local copy of springboot.bzl and it's been fairly simple to just add name + to include the parent target name for these intermediate and generated files. It all works except that git.properties retains this temporary name in the final jar. I suspect all that's needed is to add the destination filename git.properties to the springboot_pkg.sh#L211 script.

I'd be happy to raise a PR for this, but I saw from #69 that there might be some changes in the pipeline for Docker support, so I was wondering if that's something to deal with at the same time. For example, I'm thinking it might be useful to refactor the whole springboot macro into a rule with a custom Provider, which can then be consumed by a springboot_image rule - as that would otherwise have to depend on specific macro-generated targets (which then introduces visibility questions).

[plaird]

Hi @Zetten thanks for the Issue. I have been off in other worlds and hadn't had time to review your proposal here. I would welcome the proposed change. I think it will be a while before we get to the Docker layering features. I would also point to #3 as other big work in the plan that would change the implementation here. But I don't think we will tackle either in the next few months. Some comments made today at BazelCon make me think it will be good to get that work going with the Bazel 5 release.