I was looking at the vmware jar and realized it's just a jaxws generated client stubs. I'm sure this has been discussed before, so I'm curious why we can't just download the wsdl and generate the stubs ourselves? I assume we can't distribute the wsdl's, so we can just check in the java code minus the wsdl. That should work fine at runtime. I downloaded the sdk and generated the client with the below command and its 100% compatible with the vim25.jar
~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p com.vmware.vim25 vim25/vimService.wsdl Darren On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers <h...@trippaers.nl> wrote: > Hey all, > > This is something we wanted to do for a long time, but never got started > as far as i know. With some time on my hands i've made some progress on > this. I just pushed the branch vmwaresdk-to-vijava to git. In this branch > i've changed the poms to use the vijava library (version 5.1) and i've > started fixing all resulting compile errors. > > It is not a complete drop in replacement, but apparently just enough to > make it work with a few changes. The major issues i've encountered so far > by working my way through VmwareResource.java are > * changes to enums, slightly different naming convention for the values > * vijava used arrays where vmware sdk uses lists > * changes names of exceptions. > > I've fixed all compile issues in VmwareResource.java at the moment and i > will keep at it. If somebody want to pitch in, feel free. Just pick a file > with compile errors and fix it :-) > > So far i've not focussed on the potential benefits of the vijava library, > let's get it compiling first so we can do some testing with the new library. > > Is anybody planning some major work on the vmware stuff in CS? If you do, > please let me know, so we can coordinate otherwise this will be a bother to > merge into master eventually. ;-) > > Cheers, > > Hugo
