Hi all,
My apologies if I did something wrong with the squash. I can see that for some
funny reason my local and Github users got mixed, I guess that's ok. As I said,
I'm new both to Git and Github.
@andrewgaul asked a few days ago why we needed those `Long.valueOf`and I
replied with that refer
This PR changes jclouds' OSGi import directive for guava to allow version range
[16.x-19.0]. This helps dependent projects mix jclouds with bundles using other
guava versions within OSGi environments.
According to https://issues.apache.org/jira/browse/JCLOUDS-622 jclouds was made
to use only gu
For reference, here is an analysis of guava's API compatibility across
versions: http://upstream.rosalinux.ru/java/versions/guava.html
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/934#issuecomment-194314513
+1, looks like this has already been discussed at
https://issues.apache.org/jira/browse/JCLOUDS-534
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/934#issuecomment-194322876
> @@ -83,6 +83,6 @@
>
>
>
> -
> + -->
I'm not an OSGi expert, but could you please explain why this should be
commented?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/934/files#r55595004
>
> public abstract class BaseProfitBricksRequestBinder implements MapBinder {
>
> + protected final String endpointPath = "/rest/v2";
Don't hardcode this. Extract it from the provider metadata. To do so:
* Add a parameter to the constructor: `Supplier endpointSupplier`. This
will provide
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
Is this a global image that is supposed to exist?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/
Almost there! Just a couple final comments.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/245#issuecomment-194531172
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
Only specific images support sshKeys. The other option was to fetch all public
images and then filter them by name "Ubuntu-15.05...".
---
Reply
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
Actually I take it back, whenever PB updates their images the UUIDs change. So
I think we will have to grab images by name and location.
---
Rep
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
Live tests take time. If there is a way to avoid hardcoding image ids (that
eventually change when the provider updates the image list), then I'd
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
I'm afraid of introducing more complexity to the unit test. If we add this this
test wouldn't be atomic any more.
These tests won't be ran too o
> @@ -206,6 +206,7 @@
>
> gitsite:g...@github.com/jclouds/jclouds-maven-site.git
> 1.3.0
> 16.0.1
> +
> com.google.common.*;version="[16.0.1,19.0.0]"
Should this be half-closed notation, e.g., [16.0.1,20.0.0) ?
---
Reply to this email directly or view it on GitHub:
https://git
Pushed to master as
[ca57d90d](http://git-wip-us.apache.org/repos/asf/jclouds-labs/commit/ca57d90d).
Thanks!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/244#issuecomment-194537268
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
The same way you create the datacenter in the before class, can't you get the
list of available images and get a proper one?
Once everything is
Closed #244.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/244#event-584025482
> @@ -206,6 +206,7 @@
>
> gitsite:g...@github.com/jclouds/jclouds-maven-site.git
> 1.3.0
> 16.0.1
> +
> com.google.common.*;version="[16.0.1,19.0.0]"
FTR, these are the Guava versions we are compatible with (failed builds are due
to transient issues):
https://jclouds.ci.cloudb
>.licenceType(LicenceType.LINUX)
> + .type(VolumeType.HDD)
> + .image("362c903a-df61-11e5-80a4-52540005ab80")
In that case we'll have to add it :)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/245/file
18 matches
Mail list logo
