Open Zetten opened 2 years ago
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.
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
andmyservice_standalone
, there are a couple of problems:springboot
macro also wants to generate hardcoded identically-named files -MANIFEST.MF
,git.properties
andbazelrun_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 thatgit.properties
retains this temporary name in the final jar. I suspect all that's needed is to add the destination filenamegit.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 aspringboot_image
rule - as that would otherwise have to depend on specific macro-generated targets (which then introduces visibility questions).