jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi Barrera <n...@apache.org>
Subject Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Date Thu, 18 Mar 2021 11:13:50 GMT
> 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.

I don't quite get this. Doesn't the maven-shade-plugin *relocation* do this
precisely? I remember using the shade plugin in the past to shade
dependencies, and IIRC
the shade plugin took care of updating all imports in jclouds to use the
shaded+relocated libraries.
It should be possible to shade+relocate outside jclouds.



On Thu, Mar 18, 2021 at 11:31 AM Fritz Elfert <fritz@fritz-elfert.de> wrote:

> 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
>

Mime
View raw message