You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Gaul <ga...@apache.org> on 2021/03/06 13:46:19 UTC
[ANNOUNCE] Apache jclouds 2.3.0 released
The Apache jclouds team is pleased to announce the release of jclouds
2.3.0.
Apache jclouds is an open source multi-cloud toolkit for the Java
platform that gives you the freedom to create applications that are
portable across clouds while giving you full control to use
cloud-specific features.
The source archives for the release are available here:
https://jclouds.apache.org/start/install/
The Maven artifacts for the release are available in Maven Central,
under the org.apache.jclouds group ID.
The release notes are available here:
https://jclouds.apache.org/releasenotes/2.3.0/
We welcome your help and feedback. For more information on how to report
problems, and to get involved, visit the project website at:
https://jclouds.apache.org/
The Apache jclouds Team
--
Andrew Gaul
http://gaul.org/
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by "Jean-Noël Rouvignac (ForgeRock)" <je...@forgerock.com>.
>
> Here is my first attempt, but I am afraid this may be API breaking:
> https://github.com/apache/jclouds/pull/102
> Let me know what you think.
>
Unfortunately this first step is not even compiling and I don't see how to
make it work, so I declined the pull request for now.
Having looked another time at jclouds code in various places, I can see the
use of guava is extremely pervasive (as previously discussed).
Maybe this first change was way too ambitious given my very limited
knowledge of guava.
I'll see if I can come up with simpler changes that move the needle a bit
less, but can actually be merged.
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by "Jean-Noël Rouvignac (ForgeRock)" <je...@forgerock.com>.
Le dim. 21 mars 2021 à 22:16, Jean-Noël Rouvignac (ForgeRock) <
jean-noel.rouvignac@forgerock.com> a écrit :
> Le dim. 21 mars 2021 à 08:13, Andrew Gaul <ga...@apache.org> a écrit :
>
>> On Thu, Mar 18, 2021 at 10:39:05AM +0100, Jean-Noėl Rouvignac (ForgeRock)
>> wrote:
>> > I have started looking at ListenableFuture.
>> > TBH I don't know where to start! A lot of things are public, so I don't
>> > think I can change them straight from ListenableFuture to
>> CompletableFuture?
>> > They are also often used in conjunction with ListeningExecutorService
>> which
>> > makes the problem worse.
>>
>> Ugh, I incorrectly believed that ListenableFuture inherited from
>> CompletableFuture but instead they both inherit from Future. There does
>> not seem to be an easy path forward here. In the past we have done some
>> heavyweight @Deprecate-and-change-the-interface changes but these are a
>> lot of work. I would add that the only important ones to change are the
>> interfaces, not the implementation. Thus something like
>>
>> ListenableFuture<ExecResponse>
>> BaseComputeService.submitScriptOnNode(String id, String runScript,
>> RunScriptOptions options)
>>
>> is problematic but
>>
>> Set<? extends NodeMetadata>
>> BaseComputeService.resumeNodesMatching(Predicate<? super NodeMetadata>
>> filter)
>>
>> is not. In an ideal future Guava would be an implementation detail and
>> not part of the interface
>>
>
Here is my first attempt, but I am afraid this may be API breaking:
https://github.com/apache/jclouds/pull/102
LEt me know what you think.
--
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by "Jean-Noël Rouvignac (ForgeRock)" <je...@forgerock.com>.
Le dim. 21 mars 2021 à 08:13, Andrew Gaul <ga...@apache.org> a écrit :
> On Thu, Mar 18, 2021 at 10:39:05AM +0100, Jean-Noėl Rouvignac (ForgeRock)
> wrote:
> > I have started looking at ListenableFuture.
> > TBH I don't know where to start! A lot of things are public, so I don't
> > think I can change them straight from ListenableFuture to
> CompletableFuture?
> > They are also often used in conjunction with ListeningExecutorService
> which
> > makes the problem worse.
>
> Ugh, I incorrectly believed that ListenableFuture inherited from
> CompletableFuture but instead they both inherit from Future. There does
> not seem to be an easy path forward here. In the past we have done some
> heavyweight @Deprecate-and-change-the-interface changes but these are a
> lot of work. I would add that the only important ones to change are the
> interfaces, not the implementation. Thus something like
>
> ListenableFuture<ExecResponse>
> BaseComputeService.submitScriptOnNode(String id, String runScript,
> RunScriptOptions options)
>
> is problematic but
>
> Set<? extends NodeMetadata>
> BaseComputeService.resumeNodesMatching(Predicate<? super NodeMetadata>
> filter)
>
> is not. In an ideal future Guava would be an implementation detail and
> not part of the interface
>
> I also found some ListenableFuture vs. CompletableFuture migration tips:
>
> https://github.com/krka/java8-future-guide
>
> Finally it might be worth looking through other projects which
> struggling with Guava dependency issues, e.g.,
> https://issues.apache.org/jira/browse/HADOOP-17098 . jclouds is not
> alone in its Guava over-dependency.
>
Oh! Excellent! Thanks for these pointers. I quickly looked for some but did
not find any that was compelling.
> > I have noticed a lot of usages of Guava functional interfaces. These
> could
> > be replaced by JDK functional interfaces, but I have the same with public
> > constructors / APIs. Plus I think I may have a problem with Guice if it
> > uses reflection to instantiate the objects. I am only guessing this could
> > be a problem without any proof yet.
> > Doing that, I realized there was a lot of code which could be using
> lambdas
> > instead of creating subclasses of guavas functional interfaces.
> > I think this would be a step in the right direction because lambdas are
> not
> > linked to the type they implement, so it becomes easier to switch from
> > guava functional interfaces to Java functional interfaces. This is doable
> > because jclouds is now using Java 8.
> > How do you feel about the use of lambdas in jclouds?
> >
> > I also noticed a lot of generic type parameters can now be removed
> because
> > type inference has improved a lot with Java 8.
> > Would you be OK with PRs removing unnecessary generic type parameters?
>
> -1 on cosmetic changes. If you can cast these into an automated tool
> like google-java-format or refaster we could discuss this (not an IDE
> magically changing a bunch of things) but even then I view these as low
> value tasks. For example I hate 3-space indentation as much as everyone
> else but the costs far outweigh the benefits. Honestly I maintain
> several projects and there are not enough hours in the day to stay on
> top of all of the functional changes and bug reports let alone
> formatting changes.
>
OK, I will refrain from going there too much then.
I think I will first start with a small PR to see if I am on the right
tracks.
--
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Andrew Gaul <ga...@apache.org>.
On Thu, Mar 18, 2021 at 10:39:05AM +0100, Jean-Noël Rouvignac (ForgeRock) wrote:
> I have started looking at ListenableFuture.
> TBH I don't know where to start! A lot of things are public, so I don't
> think I can change them straight from ListenableFuture to CompletableFuture?
> They are also often used in conjunction with ListeningExecutorService which
> makes the problem worse.
Ugh, I incorrectly believed that ListenableFuture inherited from
CompletableFuture but instead they both inherit from Future. There does
not seem to be an easy path forward here. In the past we have done some
heavyweight @Deprecate-and-change-the-interface changes but these are a
lot of work. I would add that the only important ones to change are the
interfaces, not the implementation. Thus something like
ListenableFuture<ExecResponse> BaseComputeService.submitScriptOnNode(String id, String runScript, RunScriptOptions options)
is problematic but
Set<? extends NodeMetadata> BaseComputeService.resumeNodesMatching(Predicate<? super NodeMetadata> filter)
is not. In an ideal future Guava would be an implementation detail and
not part of the interface
I also found some ListenableFuture vs. CompletableFuture migration tips:
https://github.com/krka/java8-future-guide
Finally it might be worth looking through other projects which
struggling with Guava dependency issues, e.g.,
https://issues.apache.org/jira/browse/HADOOP-17098 . jclouds is not
alone in its Guava over-dependency.
> I have noticed a lot of usages of Guava functional interfaces. These could
> be replaced by JDK functional interfaces, but I have the same with public
> constructors / APIs. Plus I think I may have a problem with Guice if it
> uses reflection to instantiate the objects. I am only guessing this could
> be a problem without any proof yet.
> Doing that, I realized there was a lot of code which could be using lambdas
> instead of creating subclasses of guavas functional interfaces.
> I think this would be a step in the right direction because lambdas are not
> linked to the type they implement, so it becomes easier to switch from
> guava functional interfaces to Java functional interfaces. This is doable
> because jclouds is now using Java 8.
> How do you feel about the use of lambdas in jclouds?
>
> I also noticed a lot of generic type parameters can now be removed because
> type inference has improved a lot with Java 8.
> Would you be OK with PRs removing unnecessary generic type parameters?
-1 on cosmetic changes. If you can cast these into an automated tool
like google-java-format or refaster we could discuss this (not an IDE
magically changing a bunch of things) but even then I view these as low
value tasks. For example I hate 3-space indentation as much as everyone
else but the costs far outweigh the benefits. Honestly I maintain
several projects and there are not enough hours in the day to stay on
top of all of the functional changes and bug reports let alone
formatting changes.
--
Andrew Gaul
http://gaul.org/
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by "Jean-Noël Rouvignac (ForgeRock)" <je...@forgerock.com>.
I have started looking at ListenableFuture.
TBH I don't know where to start! A lot of things are public, so I don't
think I can change them straight from ListenableFuture to CompletableFuture?
They are also often used in conjunction with ListeningExecutorService which
makes the problem worse.
I have noticed a lot of usages of Guava functional interfaces. These could
be replaced by JDK functional interfaces, but I have the same with public
constructors / APIs. Plus I think I may have a problem with Guice if it
uses reflection to instantiate the objects. I am only guessing this could
be a problem without any proof yet.
Doing that, I realized there was a lot of code which could be using lambdas
instead of creating subclasses of guavas functional interfaces.
I think this would be a step in the right direction because lambdas are not
linked to the type they implement, so it becomes easier to switch from
guava functional interfaces to Java functional interfaces. This is doable
because jclouds is now using Java 8.
How do you feel about the use of lambdas in jclouds?
I also noticed a lot of generic type parameters can now be removed because
type inference has improved a lot with Java 8.
Would you be OK with PRs removing unnecessary generic type parameters?
Cheers,
Jean-Noel
Le jeu. 18 mars 2021 à 09:47, Andrew Gaul <ga...@apache.org> a écrit :
> On Thu, Mar 18, 2021 at 09:38:19AM +0100, Jean-Noėl Rouvignac (ForgeRock)
> wrote:
> > Thanks for highlighting ListenableFuture for a start. Given the size of
> > jclouds (about 400kLOC of production code with a stupid wc -l) and my
> > inexperience of its codebase, I need help to know where to start. :)
> > I'll see what I can do about it. Do you want to create an issue that
> > describes this work and what you expect out of it?
> >
> > You also mentioned that some public APIs return `ImmutableMap`. Have
> these
> > methods been deprecated in favour of an overload returning a `Map`?
>
> I think opening a JIRA issue describing the possible improvements makes
> sense since this spans several PRs (and we should open issues for all
> functional changes to make release notes work anyway). ImmutableMap is
> another good place to start -- some style guides suggest returning
> ImmutableMap instead of Map to hint at immutability but this
> unnecessarily makes the interface reliant on Guava. I would have to
> look at interface-maven-plugin again to see everything but unfortunately
> I ran into issues with the way jclouds uses public access across
> subpackages.
>
> --
> Andrew Gaul
> http://gaul.org/
>
--
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Andrew Gaul <ga...@apache.org>.
On Thu, Mar 18, 2021 at 09:38:19AM +0100, Jean-Noël Rouvignac (ForgeRock) wrote:
> Thanks for highlighting ListenableFuture for a start. Given the size of
> jclouds (about 400kLOC of production code with a stupid wc -l) and my
> inexperience of its codebase, I need help to know where to start. :)
> I'll see what I can do about it. Do you want to create an issue that
> describes this work and what you expect out of it?
>
> You also mentioned that some public APIs return `ImmutableMap`. Have these
> methods been deprecated in favour of an overload returning a `Map`?
I think opening a JIRA issue describing the possible improvements makes
sense since this spans several PRs (and we should open issues for all
functional changes to make release notes work anyway). ImmutableMap is
another good place to start -- some style guides suggest returning
ImmutableMap instead of Map to hint at immutability but this
unnecessarily makes the interface reliant on Guava. I would have to
look at interface-maven-plugin again to see everything but unfortunately
I ran into issues with the way jclouds uses public access across
subpackages.
--
Andrew Gaul
http://gaul.org/
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by "Jean-Noël Rouvignac (ForgeRock)" <je...@forgerock.com>.
Great!
Thanks for highlighting ListenableFuture for a start. Given the size of
jclouds (about 400kLOC of production code with a stupid wc -l) and my
inexperience of its codebase, I need help to know where to start. :)
I'll see what I can do about it. Do you want to create an issue that
describes this work and what you expect out of it?
You also mentioned that some public APIs return `ImmutableMap`. Have these
methods been deprecated in favour of an overload returning a `Map`?
Le jeu. 18 mars 2021 à 09:27, Andrew Gaul <ga...@apache.org> a écrit :
> On Thu, Mar 18, 2021 at 09:16:51AM +0100, Jean-Noėl Rouvignac (ForgeRock)
> wrote:
> > 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.
>
> We will gladly accept PRs which improve dependency issues and I
> appreciate you removing xmlbuilder! Java 8 introduced CompletableFuture
> so it is possible to migrate from ListenableFuture. Some technical debt
> has accumulated over the years but we should keep chipping away at it.
> I do think that using Guava in the public interfaces makes it difficult
> to shade this dependency and thus ListenableFuture might be an easy
> place to start.
>
> --
> Andrew Gaul
> http://gaul.org/
>
--
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Andrew Gaul <ga...@apache.org>.
On Thu, Mar 18, 2021 at 09:16:51AM +0100, Jean-Noël Rouvignac (ForgeRock) wrote:
> 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.
We will gladly accept PRs which improve dependency issues and I
appreciate you removing xmlbuilder! Java 8 introduced CompletableFuture
so it is possible to migrate from ListenableFuture. Some technical debt
has accumulated over the years but we should keep chipping away at it.
I do think that using Guava in the public interfaces makes it difficult
to shade this dependency and thus ListenableFuture might be an easy
place to start.
--
Andrew Gaul
http://gaul.org/
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Fritz Elfert <fr...@fritz-elfert.de>.
On 18.03.21 21:01, Ignasi Barrera wrote:
> Glad to see it still works! :)
> Mind sharing in the jclouds user list as well, to close the discussion? (You replied just to me, probably by mistake :D)
>
> On Thu, Mar 18, 2021, 20:54 Fritz Elfert <fritz@fritz-elfert.de <ma...@fritz-elfert.de>> wrote:
>
> On 18.03.21 12:13, Ignasi Barrera wrote:
> > > 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.
> >
>
> You are right of course. I had a stupid typo in my shading config which triggered tons of errors. So I gave up too quickly.
> After fixing my typo, everything went as usual and I only need to fix a few locations in my code.
>
> Thanks for bringing back my confidence in maven-shade-plugin :-)
> -Fritz
>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Ignasi Barrera <na...@apache.org>.
> 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 <fr...@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
>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Fritz Elfert <fr...@fritz-elfert.de>.
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
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by "Jean-Noël Rouvignac (ForgeRock)" <je...@forgerock.com>.
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 <fr...@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>
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Andrew Gaul <ga...@apache.org>.
On Thu, Mar 18, 2021 at 08:57:19AM +0100, Fritz Elfert wrote:
> 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)
Right, this was intended to help remove some of the problematic Guava
usage that prevent shading.
> 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
Sorry, I meant to say shading. Vendoring is a related concept used in
the Go community.
--
Andrew Gaul
http://gaul.org/
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Fritz Elfert <fr...@fritz-elfert.de>.
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
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Andrew Gaul <ga...@apache.org>.
On Wed, Mar 17, 2021 at 10:39:34PM +0100, Fritz Elfert wrote:
> Nice to see some progress. BUT:
>
> As the maintainer of the jclouds jenkins-plugin, unfortunately I'm now
> facing a problem which I can't solve by myself: The move to newer guice/guava
> breaks compatibility with jenkins (which uses guice-4.0/guava-11.0.1).
> I tried shading guice and guava in the plugin with no success.
> I'm afraid, the only proper solution would be shading guice & guava in
> jclouds.
>
> So here is my question:
>
> Would you guys accept a PR for shading guice & guava in jclouds?
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
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.
--
Andrew Gaul
http://gaul.org/
Re: [ANNOUNCE] Apache jclouds 2.3.0 released
Posted by Fritz Elfert <fr...@fritz-elfert.de>.
Nice to see some progress. BUT:
As the maintainer of the jclouds jenkins-plugin, unfortunately I'm now
facing a problem which I can't solve by myself: The move to newer guice/guava
breaks compatibility with jenkins (which uses guice-4.0/guava-11.0.1).
I tried shading guice and guava in the plugin with no success.
I'm afraid, the only proper solution would be shading guice & guava in
jclouds.
So here is my question:
Would you guys accept a PR for shading guice & guava in jclouds?
Thanks
-Fritz
On 06.03.21 14:46, Andrew Gaul wrote:
> The Apache jclouds team is pleased to announce the release of jclouds
> 2.3.0.
>
> Apache jclouds is an open source multi-cloud toolkit for the Java
> platform that gives you the freedom to create applications that are
> portable across clouds while giving you full control to use
> cloud-specific features.
>
> The source archives for the release are available here:
> https://jclouds.apache.org/start/install/
>
> The Maven artifacts for the release are available in Maven Central,
> under the org.apache.jclouds group ID.
>
> The release notes are available here:
> https://jclouds.apache.org/releasenotes/2.3.0/
>
> We welcome your help and feedback. For more information on how to report
> problems, and to get involved, visit the project website at:
> https://jclouds.apache.org/
>
> The Apache jclouds Team
>