On 18.03.21 09:16, Jean-Noël Rouvignac (ForgeRock) wrote:
The experience with shading in my company is mixed at best. Yes you go past the classpath issue, but then it becomes a maintenance nightmare if any vulnerability is detected on the shaded version (true story). Another problem may be that vulnerability scanners may not detect shaded library and fail to report vulnerability issues.
I think, githubs dependabot should still be able to scan. After all it uses the poms in the source and those still contain the original unshaded dependencies. But in general you are right of course. For me in particular, the problem is: I cannot shade transient dependencies, because all the imports in jclouds have to be changed accordingly. Therefore, doing the shading in jclouds ist the only intermediate way to get the new jclouds into my jenkins plugin.
Then a dependent project has to open the jar at build time, rehade the vulnerable library and repackage the original jar into your own version. Nobody wants to do that. The real problem is that guava does not follow semantic versioning. And there's no cure for that. Despite all its goodness, guava is not a great dependency to have because of that. It works well for them because they are in a monrepo and have powerful refactoring tools to fix all their codebase in a single commit. Conclusion: there is no magic answer to solving this problem and I did not contribute much to helping you with it. Side note: I am interested in helping reduce the reliance on guava (as I did with xmlbuilder). I am not even contemplating getting rid of it given how deeply it is used. But we need to start somewhere. Less adherence == potentially less breakage.
Maybe I can join in on the effort, having a look at all those ImmutableX collections. Cheers -Fritz
OpenPGP_0x6E8338980332A6B0.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
