jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Custine <chris.cust...@gmail.com>
Subject Re: DigitalOcean v2 to 1.9.x
Date Tue, 30 Jun 2015 23:16:40 GMT
I'm +1 for moving consolidating oauth to jclouds-labs and releasing it 
from there in 1.9.1.

Chris Custine

> Ignasi Barrera <mailto:nacx@apache.org>
> June 27, 2015 at 4:04 PM
> Hi!
> We're about to open PRs to merge the DigitalOcean v2 provider. Since
> the v1 version will no longer be available starting on November [1]
> (and is the only one we support now), I think we should include the v2
> provider in 1.9.1. This will give users enough time to migrate and
> test the new API (there are no breaking changes in it) before it is
> shut down.
> Before doing that, we have to agree how to proceed with its OAuth
> dependency. DigitalOcean v2 depends on the OAuth API, which was
> promoted to the main repo but only in 2.0.0, to avoid a groupId
> change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
> This gives us the following options:
> * Merge the digitalocean2 provider in jclouds-labs, and change the
> "build order". jclouds-labs-google will have to be built before
> jclouds-labs.
> * Move the oauth api to jclouds-labs, and then merge digitalocean2
> there. This implies that jclouds-labs-google will need to be built
> after jclouds-labs, but that's what we are already doing implicitly.
> The main issue here is that we are introducing a dependency between
> labs repos we don't have now, but I think that having the DO v2
> provider in 1.9.1 is worth it.
> if there is an agreement to proceed, I'd vote for option 2 (move oauth
> then merge the provider).
> Take into account that there are no references to 'google' in ithe
> OAuth api; it is just hosted in the labs-google repo. This means most
> users won't be affected, as the Maven coordinates won't change.
> I.
> [1] 
> https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message