Fetching dependencies from private maven server causes classes to fail to load

[t-rad679]

When I fetch my maven dependencies from our corporate maven server (Artifactory) instead of maven central, Spring Boot fails to load the classes from those nested jars. Specifically, I get a ClassNotFoundException on SpringApplication. I confirmed the issue has something to do with the paths inside the jar where the nested dependency jars are located by modifying springboot_pkg.sh so that it just drops all the bazel-out and else case deps into the root of BOOT-INF/lib/...When I bazel run with this modification, I get past the error I was seeing.

My only guess as to why it's failing is the special characters in the credentials that rules_jvm_external adds to the Artifactory path are somehow throwing off the Spring class loader. Ultimately this is probably a bug in Spring, but I think it would be easier to find a fix here.

For more context see discussion #267

[plaird]

When I saw your gist, I worried about those paths too. Thank you for tracking down the issue!

In short, there is some utility in having the subdirs in BOOT-INF/lib just in case there are multiple (different) libs with the same name. But it seems like the filtering logic we have there to truncate the paths to something reasonable is not working in all cases. Maybe this is due to a change to rules_jvm_external that we got in an upgrade.

Roughly:

• Work on the logic here: https://github.com/salesforce/rules_spring/blob/main/springboot/springboot_pkg.sh#L218
• Create a test for this somehow

[t-rad679]

It's not actually hitting the line you referenced in my case. If I'm not mistaken it was hitting the bazel-out case. My paths don't contain the word public (which makes sense since the repository is private). My impression was that ${libdir#*public} would exclude the problematic part of the path in the case you linked to.

Anyway I confirmed that removing the % characters gets it to work. Do you have any opinions on the way that you would prefer the characters removed? Are there any other characters you think would be an issue?

By "the way the characters are removed" I'm referring to things like:

• I could just remove the % outright and leave the path
• I could remove the % with the numbers that follow since this was added to escape another special character
• I could unescape the character, if that won't also cause problems.
• I could replace whatever we remove with a / or I could not do that

[RyanRCabral]

I happened to run into this same issue and put up a suggested pull request to fix the issue #275

I've validated that this at least fixes the issue in my case but happy to adjust if needed.

[serv-inc]

@plaird @t-rad679 : can this be closed now that #275 is merged ? (nitpick)