As a feedback: The current JCloud VCloudDirectorApi is very similar to VMWare's vCloud API SDK. Both still mirror the REST HATEOUS links transversal at the payload/response substrate level. >From end user point of view, it would help not to think about the "links" because they are just marshalling/unmarshalling mechanism in REST fashion. I think a higher level "vCloudClient" on top on current VCloudDirectorApi would make it easier to use.
On Wed, Nov 6, 2013 at 2:19 PM, Paul Bell <[email protected]> wrote: > Hi again, > > Making some progress now. > > The "not wrappable as org.jclouds.compute.ComputeServiceContext" error > that I previously mentioned continues to occur. About this I discovered the > following: > > > http://mail-archives.apache.org/mod_mbox/jclouds-user/201309.mbox/%[email protected]%3e > > I think this is saying that the ComputeService implementation for VCD is > not yet finished. What does this mean? For example, per Andrew's > observation re using a provider-specific approach, am I presently > constrained to just such an approach? If so, then won't my code - at least > for the time being - be limited to a single provider (VCD)? > > The comment in the mail archives indicates that, because the VCD domain > model is implemented, it's now possible to drive the underlying VCD REST > API via Java. But this capability was already present in the VMware Java > API for VCD. > > Another question: if I am presently constrained to provider-specific API, > then will the first link that Andrew posted (MainApp.java) help me? That > is, it seems to deal in the nice jclouds abstractions, like "portable > views." But, unless I am sorely mistaken (always possible!), I don't > presently have access to these abstractions for VCD. > > That said, I will quite happily study that code to learn more of the > jclouds idiom. But my immediate need is the ability to: > > a. create one or more vApps, each consisting of one or more VMs. > b. deploy thereon an OVA/OVF > c. configure application specific stuff on these VMs > d. start them up > > Again, thank you for your help & light. > > Cordially, > > Paul > > On Wed, Nov 6, 2013 at 1:04 PM, Paul Bell <[email protected]> wrote: > >> Hi Andrew, >> >> Thank you for this guidance. >> >> I will get on it! >> >> -Paul >> >> On Wed, Nov 6, 2013 at 12:36 PM, Andrew Phillips <[email protected]>wrote: >> >>> Hi Paul >>> >>> First of all, please use 1.6.2-incubating for all the dependencies, to >>> avoid any incompatibilities arising from that. >>> >>> As regards sample code, we're probably best off looking at the >>> compute-basics example [1] and the BaseVCloudDirectorApiLiveTest [2]. >>> >>> If we want to work directly with the vendor-specific vCloud API, rather >>> than one of jclouds' portable views such as the ComputeServiceContext, we >>> can also get hold of the API directly, by the way: >>> >>> VCloudDirectorApi vcdApi = >>> >>> ContextBuilder.newBuilder("vcloud-director") >>> .endpoint("https://dpvcloud.company.com";) >>> .credentials("pbell@MyOrg", "mypassword") >>> .buildApi(VCloudDirectorApi.class); >>> >>> See the ContextBuilder Javadoc [3] for more details. >>> >>> ap >>> >>> [1] https://github.com/jclouds/jclouds-examples/blob/master/ >>> compute-basics/src/main/java/org/jclouds/examples/compute/ >>> basics/MainApp.java >>> [2] https://github.com/jclouds/jclouds-labs/blob/master/ >>> vcloud-director/src/test/java/org/jclouds/vcloud/director/v1_5/internal/ >>> BaseVCloudDirectorApiLiveTest.java >>> [3] http://javadocs.jclouds.cloudbees.net/org/jclouds/ >>> ContextBuilder.html >>> >> >> >
