Hi Suriya, Despite being in a different "labs" repository, the GCE provider is also released as part of the regular release process. You'll find the release artifacts in Maven Central [1], so you download or include them as a dependency where needed. Moving the provider to the main repository should not be a blocker for downstream projects, as long as they can use the released artifacts.
Creating the provider metadata class should be ideal, but I'm not sure if it would be a must. A "provider" in jclouds is just an "api", exposed in a concrete location, with a set of defaults (check this [2] core concept definition page). Many providers have common APIs (think about OpenStack providers). While the API they expose is the same (nova, swift, etc), the endpoints where they expose the api and some defaults change. That is what the provider metadata describes. Even though if there is no provider metadata describing a "concrete deployment of the api", you can still instanciate the provider, using the ContextBuilder normally. You can use "google-compute-engine" as the provider id, and use the default endpoint, defined by the GoogleComputeEngineApiMetadata [3]. If you have the provider dependency in your classpath, jclouds will find it and pick it up. So, taking into account these things (if I am not missing something) you should be already able to use the GCE provider without having to wait for those changes in the jclouds side. HTH! Ignasi [1] http://search.maven.org/#artifactdetails%7Corg.apache.jclouds.labs%7Cgoogle-compute-engine%7C1.7.1%7Cjar [2] http://wiki.apache.org/jclouds/Core%20Concepts [3] https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/GoogleComputeEngineApiMetadata.java#L78-L85 On 10 March 2014 09:18, Sathyasuriya Priya <sathyasur...@gmail.com> wrote: > Dear Jclouds developers, > > I am Suriyapriya Veluchamy, currently an MS CS student at NPU, Fremont, CA, > USA. > I am interested in the following GSOC project in Stratos. > https://issues.apache.org/jira/browse/STRATOS-480 > > I have some queries on the GCE support in jclouds, since this is needed for > Stratos to integrate with GCE. > https://github.com/jclouds/jclouds-labs-google > > I looked at a relevant email thread as well. > http://www.mail-archive.com/dev@jclouds.apache.org/msg04369.html > > I understand the following JIRA issue is for moving the separate GCE > project to the core project. > https://issues.apache.org/jira/browse/JCLOUDS-172 > > I would like to understand the complexity of this work, based on which I > would decide whether it could be part of my gsoc work. I have come up with > list of todo items, based on my analysis. Pls correct me or add other items > needed as well. > > 1. Create GCEProviderMetadata extending BaseProviderMetadata (similar to > AWSEC2ProviderMetadata) - this is needed for > ContextBuilder.newBuilder(provider) to pick up GCE ? > 2. Move all the files (oauth, google-compute-engine) to > jclouds-providers-project. > 3. Hopefully, jclouds should pick up GCE as provider. Fix any issues that > come up. > 4. Andrew Bayer's criticisms of OAuth code - I couldn't find the relevant > discussion/email related to this. Any idea if this is a critical piece and > how much effort is needed to fix it. > > I am assuming other jclouds components are provider agnostic and shouldn't > break. Do you aware of any other code changes needed in other components. > > Also, I came across the GCE API java library from google. Any idea why we > don't use it directly (instead rely on REST apis). May be for OAuth support > alone we can make use of this ? > https://developers.google.com/compute/docs/api/api-lib/java > > I was able to build jclouds-labs-google and run unittests successfully. > I will try to work on an example to make use of this project and will > update. > > Thanks > Suriya
