search

salesforce / rules_spring

Bazel rule for building Spring Boot apps as a deployable jar
BSD 3-Clause "New" or "Revised" License
224 stars 48 forks source link

springboot rule doesn't work when the java_library attribute references a kt_jvm_library target #81

Closed simontoens closed 3 years ago

simontoens commented 3 years ago

This is with rules kotlin version v1.5.0-alpha-3

The error is, when running the springboot jar:

Error: Invalid or corrupt jarfile path-to-jar

This error is caused by a corrupt jar manifest.

In springboot.bzl, when we use a genrule to call springboot_pkg.sh, we use the $(SRCS) syntax. For the java_library attribute, when it references a kt_jvm_library target, we get more than one file path although we expect only one. The first one we get is the jar produced by kt_jvm_library as expected. But the next one is a .jdeps file, which is unexpected. When springboot_pkg.sh runs, since it uses positional arguments, the jdeps file replaces the manifest file, and things go downhill from there. See around here: https://github.com/salesforce/bazel-springboot-rule/blob/master/tools/springboot/springboot.bzl#L350

There is a workaround - add a java_library target indirection between the kt_jvm_library target and the springboot target.

java_library(
    name = "springboot_lib",
    runtime_deps = [":<kt_jvm_library_name>"],
)
springboot(
    java_library = ":springboot_lib",
    ...

We are currently testing this workaround internally. If it works as expected, we can encapsulate this within springboot.bzl

simontoens commented 3 years ago

Just using a java_library indirection isn't equivalent, because nothing ends up in BOOT-INF/classes. The "real" jar still ends up as the first jar entry in BOOT-INF/lib, so it seems that runtime classloading order is preserved, but there may be subtle differences. I will debug this a bit more.

simontoens commented 3 years ago

the jdeps output is coming from here: https://github.com/bazelbuild/rules_kotlin/blob/master/kotlin/internal/jvm/impl.bzl#L37

plaird commented 3 years ago

I just removed some old code coverage logic that was handling a similar issue (extra positional arg). It wasn't applicable anymore to code coverage, but maybe we need to add it back for this case. See the script update in PR #80

plaird commented 3 years ago

Reminder to selves: Work on this in the 1.1.x branch, and cut a new 1.1.x release with the fix from there. Then merge to master. master will soon be back incompat with 1.x.

plaird commented 3 years ago

Released in 1.1.1 https://github.com/salesforce/bazel-springboot-rule/releases/tag/1.1.1