Re: diskURIToImage.getUnchecked() fails on instance created from snapshot (GCE)

[Fritz Elfert]

Hi,

I'm the maintainer of the jenkins jclouds-plugin and just wanted to
chime in here...

I'd suggest designing that little test program as a LiveTest (fetching
account-specifics and credentials from a local maven settings.xml). If
you like, I can help with that but not before the end of next week
(extremely busy at work right now).

Cheers
 -Fritz

On 09.03.2017 13:03, Ignasi Barrera wrote:
> I'd say you could just create a snapshot in your account and write a
> small main program that calls `listNodes` . Something like this:
> 
> try {
>String identity = "";  // Something like
> "project...@developer.gserviceaccount.com"
>String credential = Files.toString(new File(" account private key>"), Charsets.UTF_8);
> 
>ComputeServiceContext ctx =
> ContextBuilder.newBuilder("google-compute-engine")
>   .credentials(identity, credential)
>   .modules(ImmutableSet.of(new SshjSshClientModule()))
>   .buildView(ComputeServiceContext.class);
> 
>ComputeService compute = ctx.getComputeService();
> 
>compute.listNodes();   // This will fail if there are snapshots
> until the issue is fixed.
> finally {
>ctx.close();
> }
> 
> You'll just need to add the
> "org.apache.jclouds.provider/google-compute-engine" and
> "org.apache.jclouds.driver/jclouds-sshj" dependencies to run that
> small program.
> 
> 
> You can have a look at the README for more info on how to get the credentials:
> https://github.com/jclouds/jclouds/tree/master/providers/google-compute-engine
> 
> 
> HTH!
> 
> I.
> 
> On 8 March 2017 at 17:57, Tomasz Wojtun  wrote:
>> Hi Ignasi.
>>
>> I will be glad to make a pull request. Can you tell me if there is an easy 
>> way to test the fix in IDE?
>>
>> Regards,
>> Tomasz
>>
>> On 07/03/2017, 14:32, "Ignasi Barrera"  wrote:
>>
>> Hi Tomasz,
>>
>> You're right. jclouds should not fail in that case, The
>> "diskuRIToImage" in the InstanceToNodeMetadata class is a cache, and
>> it makes no sense to try to load a "null" key. I'd say the right way
>> to fix it is just to execute this [1] only if the input disk's source
>> is not null. Do you want to try opening a pull request with a patch?
>> I'd be happy to help!
>>
>>
>> I.
>>
>> [1] 
>> https://github.com/jclouds/jclouds/blob/master/providers/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/functions/InstanceToNodeMetadata.java#L77
>>
>>
>> On 7 March 2017 at 13:31, Tomasz Wojtun  
>> wrote:
>> > Hi Jclouds users.
>> >
>> >
>> >
>> > I want to use  jclouds-plugin on Jenkins to provide jenkina slave 
>> machines
>> > on Google Compute.
>> >
>> > The plugin fails to count nodes with specific images, when it comes up 
>> on
>> > instance created from snapshot.
>> >
>> > The cause seems to be in jclouds code.
>> >
>> > Shouldn’t diskURIToImage.getUnchecked() in InstanceToNodeMetadata 
>> return
>> > null and not throw an error in this case?
>> >
>> >
>> >
>> > Best regards,
>> >
>> > Tomasz
>> >
>> >
>> >
>> > StackTrace:
>> >
>> > Timer task 
>> hudson.slaves.NodeProvisioner$NodeProvisionerInvoker@79b4d01d
>> > failed
>> > shaded.com.google.common.util.concurrent.UncheckedExecutionException:
>> > java.util.concurrent.ExecutionException: could not find image for disk
>> > 
>> https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/disks/INSTANCE_NAME:
>> > endpoint for [0] not configured for
>> > org.jclouds.googlecomputeengine.compute.functions.Resources.public 
>> abstract
>> > org.jclouds.googlecomputeengine.domain.Image
>> > 
>> org.jclouds.googlecomputeengine.compute.functions.Resources.image(java.net.URI)
>> > at
>> > 
>> shaded.com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4829)
>> > at
>> > 
>> org.jclouds.googlecomputeengine.compute.functions.InstanceToNodeMetadata.apply(InstanceToNodeMetadata.java:77)
>> > at
>> > 
>> org.jclouds.googlecomputeengine.compute.functions.InstanceToNodeMetadata.apply(InstanceToNodeMetadata.java:43)
>> > at
>> > 
>> shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:211)
>> > at
>> > 
>> shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:794)
>> > at
>> > 
>> shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
>> > at
>> > 
>> shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:646)
>> > at
>> > 
>> shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>> > at
>> > 
>> shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>> > at 
>> shaded.com.google.common.collect.Iterators.addAll(Iterators.java:356)
>> > at 
>> 

Re: diskURIToImage.getUnchecked() fails on instance created from snapshot (GCE)

[Fritz Elfert]

Yes, LGTM.

-Fritz

On 14.03.2017 09:44, Ignasi Barrera wrote:
> I've just merged the PR: https://github.com/jclouds/jclouds/pull/1076
> Fritz, the provided mock test properly covers the change so I think
> there is no need for the specific live test. Do you agree?
> 
> 
> Thanks!
> 
> I.
> 
> On 13 March 2017 at 11:13, Tomasz Wojtun <tomasz.woj...@stepstone.com> wrote:
>> It would need to  either create an instance from a snapshot and then call
>> listNodes, or call DiskUriToImage.load(URI_TO_SNAPSHOT) directly.
>>
>> I have submitted a pull request with a fix and a mock test.
>>
>> Please take a look @ https://github.com/jclouds/jclouds/pull/1075
>>
>>
>>
>> Cheers,
>>
>> Tomek
>>
>>
>>
>> From: Ignasi Barrera <n...@apache.org>
>> Reply-To: "user@jclouds.apache.org" <user@jclouds.apache.org>
>> Date: Monday, 13 March 2017 at 09:43
>> To: "user@jclouds.apache.org" <user@jclouds.apache.org>
>> Subject: Re: diskURIToImage.getUnchecked() fails on instance created from
>> snapshot (GCE)
>>
>>
>>
>> Absolutely. A live test would be perfect.
>>
>>
>>
>> I'd add a test method to the compute service adapter live test that takes an
>> snapshot of one of the created test nodes and then calls getNode.
>>
>>
>>
>> I'm not very familiar with the GCE API though, and I only see there methods
>> to create snapshots of a given Disk. Would that be enough to replicate the
>> failure scenario for the test?
>>
>>
>>
>>
>>
>> On Mar 9, 2017 22:03, "Fritz Elfert" <fr...@fritz-elfert.de> wrote:
>>
>> Hi,
>>
>> I'm the maintainer of the jenkins jclouds-plugin and just wanted to
>> chime in here...
>>
>> I'd suggest designing that little test program as a LiveTest (fetching
>> account-specifics and credentials from a local maven settings.xml). If
>> you like, I can help with that but not before the end of next week
>> (extremely busy at work right now).
>>
>> Cheers
>>  -Fritz
>>
>> On 09.03.2017 13:03, Ignasi Barrera wrote:
>>> I'd say you could just create a snapshot in your account and write a
>>> small main program that calls `listNodes` . Something like this:
>>>
>>> try {
>>>String identity = "";  // Something like
>>> "project...@developer.gserviceaccount.com"
>>>String credential = Files.toString(new File(">> account private key>"), Charsets.UTF_8);
>>>
>>>ComputeServiceContext ctx =
>>> ContextBuilder.newBuilder("google-compute-engine")
>>>   .credentials(identity, credential)
>>>   .modules(ImmutableSet.of(new SshjSshClientModule()))
>>>   .buildView(ComputeServiceContext.class);
>>>
>>>ComputeService compute = ctx.getComputeService();
>>>
>>>compute.listNodes();   // This will fail if there are snapshots
>>> until the issue is fixed.
>>> finally {
>>>ctx.close();
>>> }
>>>
>>> You'll just need to add the
>>> "org.apache.jclouds.provider/google-compute-engine" and
>>> "org.apache.jclouds.driver/jclouds-sshj" dependencies to run that
>>> small program.
>>>
>>>
>>> You can have a look at the README for more info on how to get the
>>> credentials:
>>>
>>> https://github.com/jclouds/jclouds/tree/master/providers/google-compute-engine
>>>
>>>
>>> HTH!
>>>
>>> I.
>>>
>>> On 8 March 2017 at 17:57, Tomasz Wojtun <tomasz.woj...@stepstone.com>
>>> wrote:
>>>> Hi Ignasi.
>>>>
>>>> I will be glad to make a pull request. Can you tell me if there is an
>>>> easy way to test the fix in IDE?
>>>>
>>>> Regards,
>>>> Tomasz
>>>>
>>>> On 07/03/2017, 14:32, "Ignasi Barrera" <n...@apache.org> wrote:
>>>>
>>>> Hi Tomasz,
>>>>
>>>> You're right. jclouds should not fail in that case, The
>>>> "diskuRIToImage" in the InstanceToNodeMetadata class is a cache, and
>>>> it makes no sense to try to load a "null" key. I'd say the right way
>>>> to fix it is just to execute this [1] only if the input disk's source
>>>> is not null. Do you want to try opening a pull request with a patch?
>>>>   

Re: Problem spinning up instances on GCE with custom subnets

[Fritz Elfert]

FYI: In the meantime, Ignasi mentioned to me:
There is already https://issues.apache.org/jira/browse/JCLOUDS-1300
which also covers the same problem.

-Fritz

On 24.05.2017 00:19, Joshua Forest wrote:
> I need to be able to specify the subnetwork, is this possible in
> jclouds?  I am using the jclouds-plugin on jenkins.  Fritz Effert (the
> maintainer of that plugin) said he'd be watching the list and would
> respond if he saw something come through, so here it is! 
> 
> May 19, 2017 6:57:46 PM 
> jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate get
> INFO: Provisioning new jclouds node
> May 19, 2017 6:57:46 PM 
> jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate get
> INFO: Setting image id to https://www.googleapis.com/compute/v1/projects/
> 
> /global/images/
> May 19, 2017 6:57:46 PM 
> jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate get
> INFO: Setting hardware Id to 
> https://www.googleapis.com/compute/v1/projects/
> 
> /zones/europe-west1-c/machineTypes/n1-standard-1
> May 19, 2017 6:57:46 PM 
> jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate get
> INFO: Setting location Id to europe-west1-c
> May 19, 2017 6:57:46 PM org.jclouds.logging.jdk.JDKLogger logInfo
> INFO: >> searching 
> params({imageId=https://www.googleapis.com/compute/v1/projects/
> 
> /global/images/,
> locationId=europe-west1-c,
> hardwareId=https://www.googleapis.com/compute/v1/projects/
> 
> /zones/europe-west1-c/machineTypes/n1-standard-1})
> May 19, 2017 6:57:49 PM org.jclouds.logging.jdk.JDKLogger logInfo
> INFO: << matched image(https://www.googleapis.com/compute/v1/projects/
> 
> /global/images/)
> hardware(https://www.googleapis.com/compute/v1/projects/
> 
> /zones/europe-west1-c/machineTypes/n1-standard-1)
> location(europe-west1-c) May 19, 2017 6:57:49 PM 
> jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate get
> INFO: Setting networks to support
> May 19, 2017 6:57:49 PM 
> jenkins.plugins.jclouds.compute.JCloudsSlaveTemplate get
> INFO: Init script without private admin key. Falling back to jenkins user 
> credentials
> May 19, 2017 6:57:49 PM org.jclouds.logging.jdk.JDKLogger logInfo
> INFO: >> running 1 node group(jenkins-buildbox) location(europe-west1-c) 
> image(https://www.googleapis.com/compute/v1/projects/
> 
> /global/images/)
> hardwareProfile(https://www.googleapis.com/compute/v1/projects/
> 
> /zones/europe-west1-c/machineTypes/n1-standard-1)
> options({loginUser=admin, loginPrivateKeyPresent=true,
> scriptPresent=true, userMetadata={Name=jenkins-buildbox},
> networks=[support]}) May 19, 2017 6:57:50 PM 
> org.jclouds.logging.jdk.JDKLogger logInfo
> INFO: >> adding node location(europe-west1-c) name(jenkins-buildbox-143) 
> image(6874878162127463719) hardware(3001)
> May 19, 2017 6:57:50 PM org.jclouds.logging.jdk.JDKLogger logError
> SEVERE: createNodesInGroup(jenkins-buildbox), completed: 0/1, errors: 1, 
> rate: 586ms/op
> java.util.concurrent.ExecutionException: 
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/compute/v1/projects/
> 
> /zones/europe-west1-c/instances
> HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
> "error": {
> "errors": [
> {
> "domain": "global",
> "reason": "invalid",
> "message": "Invalid value for field 'resource.networkInterfaces[0]': ''.
> Subnetwork should be specified for custom subnetmode network"
> }
> ],
> "code": 400,
> "message": "Invalid value for field 'resource.networkInterfaces[0]': ''.
> Subnetwork should be specified for custom subnetmode network"
> }
> }
> ]
> at 
> shaded.com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> at 
> shaded.com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> at 
> shaded.com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at org.jclouds.concurrent.FutureIterables$1.run(FutureIterables.java:123)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/compute/v1/projects/
> 
> 

Re: Upgrading an application to jclouds 2.1.0

[Fritz Elfert]

Thanks a lot, Andrea for the quick response! Exactly what i needed :-)

Cheers
 -Fritz

On 01.03.2018 19:12, Andrea Turli wrote:
> Hi,
> 
> I think the commit message is slightly misleading, it should read
> `remote ServerPredicates as the functionality is duplicated`
> 
> in fact [1] serves the same purpose. At [2] you can find an example of
> how jclouds uses it now
> 
> Sorry for any inconvenience,
> Andrea
> 
> [1]: 
> https://github.com/jclouds/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/config/NovaComputeServiceContextModule.java#L197-L204
> [2]: 
> https://github.com/jclouds/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/NovaComputeServiceAdapter.java#L138
> 
> On Thu, Mar 1, 2018 at 6:58 PM, Fritz Elfert <fr...@fritz-elfert.de> wrote:
>> Hi,
>>
>> I want to upgrade a small administrative application for an internal
>> OpenStack environment to jclouds-2.1.0, however I'm stuck due to missing
>> ServerPredicates.
>>
>> In the commit message of aa11765bee8e5e7f2d062ba8123c0dced822f071,
>> Andrea Turli states:
>>
>> "- remove ServerPredicates as it is now duplicated"
>>
>> but I can't find another ServerPredicates class?!
>>
>> So: how is the following code supposed to be implemented using
>> jclouds-2.1.0 resp. what is the replacement for ServerPredicates?
>>
>> = snip ==
>> private void doSomethingWhileServerRunning(final Server s) {
>> final String sid = s.getId();
>> while (!ServerPredicates.awaitStatus(sapi,
>> Server.Status.SHUTOFF, 30, 5).apply(sid)) {
>> /* do something with the server console ... */
>> }
>> ...
>> = snip ==
>>
>> Thanks in Advance.
>>
>> -Fritz

Upgrading an application to jclouds 2.1.0

[Fritz Elfert]

Hi,

I want to upgrade a small administrative application for an internal
OpenStack environment to jclouds-2.1.0, however I'm stuck due to missing
ServerPredicates.

In the commit message of aa11765bee8e5e7f2d062ba8123c0dced822f071,
Andrea Turli states:

"- remove ServerPredicates as it is now duplicated"

but I can't find another ServerPredicates class?!

So: how is the following code supposed to be implemented using
jclouds-2.1.0 resp. what is the replacement for ServerPredicates?

= snip ==
private void doSomethingWhileServerRunning(final Server s) {
final String sid = s.getId();
while (!ServerPredicates.awaitStatus(sapi,
Server.Status.SHUTOFF, 30, 5).apply(sid)) {
/* do something with the server console ... */
}
...
= snip ==

Thanks in Advance.

-Fritz

Serious problem with OpenStack rocky and jclouds GlanceApi

[Fritz Elfert]

Hi guys,

I just tried using GlanceApi from jclouds 2.1.x against OpenStack Rocky
and it fails hopelessly because OpenStack Rocky does not support glance
API 1.0 anymore :-(

Quote from the release notes at
https://docs.openstack.org/releasenotes/glance/rocky.html:

"This release of OpenStack Glance introduces 2 new API versions. Images
API v2.7 adds support and modifications for the Hidden Images and
Multihash features introduced during Rocky cycle. Version 2.8 is
included as an optional EXPERIMENTAL API for testing and preparing for
multiple back-end support.

Rocky development cycle marks long waited milestone on Glance work. The
Images API v1 which has been deprecated for years is finally removed and
not available at all in Glance version 17.0.0 forward."


So, the obvious question is:

When will jclouds support glance-api >= 2.7 ?

Thanks in advance
 -Fritz

Re: enable dependabot on jclouds github repo(s)?

[Fritz Elfert]

On 18.03.21 15:38, Andrew Gaul wrote:

On Thu, Mar 18, 2021 at 02:21:57PM +0100, Fritz Elfert wrote:

On 18.03.21 12:14, Andrew Gaul wrote:

This is something we could experiment with although there are more
considerations for upgrading dependencies than simply getting the latest
version, as the recent thread about Guava and Guice demonstrates.  My
experience with these automatic tools is that they work better for
applications than frameworks.  We would also want to align with other
Apache projects -- do we have some similar infrastructure already?


dependabot is NOT about simply getting the latest version, but about security 
vulnerabilities.

For example im my fork of jclouds at https://github.com/felfert/jclouds I can 
see
two warnings (only the owner of the repository sees those). For each warning, I 
also got an email.
In addition, dependabot has created a PR for updating jetty. (The other 
vulnerability does not have a fix yet.)
Ok, in this case (jetty being used for tests only) it could be neglected, but I 
have seen several merged PRs
by dependabot in jenkins. Given that it is only visible to repo-owners and is 
really non-intrusive it should
not hurt to switch this on and see if it proves useful.


[I notice you only replied to me individually.  I would prefer to take
this thread back on-group if you reply to me.]

That was not intentional - I just hit the wrong reply-key, sorry. (Replying to 
the group now).



I understand that dependabot has value, even if you ignore or close the
PR, but libraries like jclouds have other considerations.  Before
jclouds 2.3.0 we maintained compatibility with Java 7 which meant that
many suggested dependency upgrades were not valid.  We can debate the
merits of that policy but it is easy to see how upgrades to Guava,
Guice, and other dependencies break some user or another.

Again, I am happy to experiment with this.   But Aligning with the
overall Apache project and reducing dependencies remain priorities.


Understood
 -Fritz


OpenPGP_0x6E8338980332A6B0.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

enable dependabot on jclouds github repo(s)?

[Fritz Elfert]

Jean-Noël mentioning security scanners in our recent discussion make me think:

It would be nice to have depedabot enabled in the github repo settings (Security 
& analysis).
If both alerts and security updates are enabled, it automatically creates pull 
requests for the relevant changes.

Cheers
 -Fritz


OpenPGP_0x6E8338980332A6B0.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [ANNOUNCE] Apache jclouds 2.3.0 released

[Fritz Elfert]

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

Re: [ANNOUNCE] Apache jclouds 2.3.0 released

[Fritz Elfert]

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 mailto:fr...@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





OpenPGP_0x6E8338980332A6B0.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [ANNOUNCE] Apache jclouds 2.3.0 released

[Fritz Elfert]

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





OpenPGP_0x6E8338980332A6B0.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [ANNOUNCE] Apache jclouds 2.3.0 released

[Fritz Elfert]

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


OpenPGP_0x6E8338980332A6B0.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature