jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noël Rouvignac (ForgeRock) <jean-noel.rouvig...@forgerock.com>
Subject Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Date Thu, 18 Mar 2021 08:16:51 GMT
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.
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.


Le jeu. 18 mars 2021 à 08:57, Fritz Elfert <fritz@fritz-elfert.de> a écrit :

> On 18.03.21 01:21, Andrew Gaul wrote
> [...]> Guava versioning is a perennial source of frustration to users and
> > maintainers.  Unfortunately jclouds (and specifically me) made poor
> > choices by using Guava types in public interfaces.  I created some
> > tooling to address this but did not make much progress fixing jclouds
> > itself:
> >
> > https://github.com/gaul/interface-maven-plugin
> >
> Thanks for the link. However, at a first glance, this looks more
> like a tool for warning about undesired class usage. The jenkins
> parent pom already uses the maven-enforcer-plugin which does something
> similar (and more) but at pom level (e.g.: in jenkins it blocks
> transitive dependency on newer guice/java for any plugin)
>
> > Would Guava/Guice vendoring work given the existing mess?  Could you
> > hack up a partial proof of concept to see if it would work?  Vendoring
> > has other caveats so let's what others say.
> >
> I am not familiar with the term vendoring. What is that?
>
> I only know shading using the maven-shade-plugin. E.g.: This
> has been used in jclouds in the past (was removed though at a later point
> in time):
>
> https://github.com/apache/jclouds/pull/35
>
> Thanks
>   -Fritz
>

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

Mime
View raw message