Agreed. If we can do it is the big question. Although, AFAIK, vijava is also generated from the same set of wsdl. So if we can't get the license, I have to wonder how did vijava get their BSD license?
--Alex > -----Original Message----- > From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] > Sent: Tuesday, September 24, 2013 6:07 PM > To: dev@cloudstack.apache.org > Cc: dev@cloudstack.apache.org > Subject: Re: VmWare SDK to vijava > > My extensive testing consisted of "it compiles!" So somebody needs to > validate it, I don't have a vmware setup handy. The wsdl generation route is > not feasible unless legal says it's okay. Somebody want to email legal@? > > Darren > > > On Sep 24, 2013, at 5:27 PM, Hugo Trippaers <h...@trippaers.nl> wrote: > > > > So at this moment we have the following tally, > > > > Darren, Alex, Kelven opt for the wsdl route Hugo opts for the vijava > > route > > > > I'm perfectly ok with ditching my work on the vijava in favour of the wsdl > route. The arguments presented in the last few mails make a lot of sense. So > i say the wsdl route is the way to go. > > > > I do think however that we need to revisit the vmware code anyway. There > is dead code in there, formatting issues and a general duplication of code. > Parts of my plan to switch to vijava was to simplify the code as well, but i > can > still do that with the WSDL layer. > > > > Darren, did you run your wsdl branch through the BVT test suite? If you did > we can merge it on short notice and get on with it. If you didn't can you take > care of that and give an overview of the testing done on that branch besides > the BVT? > > > > Cheers, > > > > Hugo > > > > > >> On Sep 25, 2013, at 2:58 AM, Kelven Yang <kelven.y...@citrix.com> > wrote: > >> > >> We have commercial releases on top of existing code base and there > >> are lots of testing efforts behind it, dramatic switch means $ cost, > >> the major concern for me is not about how beautiful vijava is or how > >> bad a direct wsdl approach would be. it is about to get things move > smoothly. > >> > >> It looks like that we should have VMware layer on its own to have a > >> plugin structure so that we can replace underlying binding easier, it > >> should solve the balance between developer's tho motivation and > >> carrying on the legacy with minimal impacts to the rest of others. > >> > >> > >> Kelven > >> > >>> On 9/23/13 6:01 PM, "Hugo Trippaers" <h...@trippaers.nl> wrote: > >>> > >>> Heya, > >>> > >>> This biggest advantage i see in using vijava is that a lot of the > >>> functionality that we now have in the vmware-base project is already > >>> supplied with vijava. > >>> > >>> There is a lot of code that facilitates calling tasks and other > >>> stuff in our MO classes. These classes are available in vijava and > >>> could be used instead of our classes. Basically when using vijava > >>> correctly you hardly have to work with the ManagedObjectReferences > >>> anymore. For me this would be a big benefit as it makes programming > >>> against vmware a lot easier. We also have a lot of duplicate code > >>> currently in the vmware class and i wouldn't mind getting rid of it, > >>> which i think is easier with the vijava libraries. > >>> > >>> That said, the main driver is getting it into the main build so any > >>> other efforts towards that goal are ok with me. > >>> > >>> I would propose that somebody else puts up a branch with our own > >>> wdsl wrapper and we open a discussion thread when both branches are > >>> ready to see which we want to merge in master. Anybody who wants to > pick that up? > >>> > >>> I'm stubbornly going to continue with converting to vijava, I put > >>> some effort into it and i want at least to see it running once ;-) > >>> And the more i work with it the more i'm seeing to benefits of the > >>> library so i might be able to be more convincing in the end :-) > >>> > >>> Cheers, > >>> > >>> Hugo > >>> > >>> > >>>> On Sep 24, 2013, at 2:18 AM, Kelven Yang <kelven.y...@citrix.com> > wrote: > >>>> > >>>> Prior to 5.1, VMware provides java binding in its SDK and this is > >>>> where CloudStack VMware integration began with. Starting from 5.1, > >>>> VMware no longer provides the java binding in binary form and > >>>> recommends its customers to generate directly from its WS WSDL. > >>>> > >>>> Since we are not sure if we can distribute VMware wsdl legally or > >>>> not, therefore, we ended up to generate and distribute the java > >>>> binding in binary form. If we can get this cleared in lebal, as > >>>> Darren pointed, we can solve our non-dist issue easily in matter of > >>>> adding couple of lines in maven. > >>>> > >>>> As of vijava, yes, I think it may add some value from developer's > >>>> point of view, but on the other hand, I don't see immediate > >>>> benefits to having another layer on top of VMware official WS API, > >>>> vijava is an open source project for providing convenient java > >>>> binding to vmware WS API, maybe I'm wrong, but I think VMware > >>>> vSphere WS API is the only official published API from VMware, and > >>>> the testing result of the API is endorsed by VMware as an > >>>> commercial entity. So I see more business value to stick with the > >>>> official WS API directly. If we can clear the legal concern of > >>>> redistributing VMware wsdl. I would +1 to add a build step of > >>>> generating VMware java binding from wsdl. > >>>> > >>>> Kelven > >>>> > >>>> > >>>>> On 9/23/13 12:40 AM, "Hugo Trippaers" <h...@trippaers.nl> wrote: > >>>>> > >>>>> We have been having this discussion on moving vmware out of > >>>>> noredist since i joined the project. So no real need to rush this > suddenly. > >>>>> Still > >>>>> it would be nice to get this in for the next release. The feature > >>>>> freeze of 4.3 is october 31st for the 4.3 release. This change (or > >>>>> any sdk change to vmware) should be considered an architecture > >>>>> change so it should come in at the start of the new release cycle. > >>>>> > >>>>> So this is currently my main activity on CloudStack meaning i can > >>>>> work pretty much dedicated on this. With a bit of luck i can have > >>>>> the changes finished this week. Then it's up to the test results > >>>>> if we can make it into the 4.3 release or the 4.4 release. Of > >>>>> course all pending a successful merge vote. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Hugo > >>>>> > >>>>> On Sep 23, 2013, at 3:10 PM, Darren Shepherd > >>>>> <darren.s.sheph...@gmail.com> wrote: > >>>>> > >>>>>> It's seems there could be some good merit to adopting vijava. I > >>>>>> hate to belabor this point, but we could get vmware plugin out of > >>>>>> noredist real fast if we just generate bindings (I think) > >>>>>> > >>>>>> Do you know if legally we can add the vmware wsdl to git? We > >>>>>> wouldn't redistribute it in the binary builds. If we could add > >>>>>> the wsdl to git, I could add a couple lines to the Pom and it > >>>>>> will generate the bindings as part of the build. Then vmware > >>>>>> will be fully redistributable and there is no change to existing > >>>>>> code. At runtime everything should be the same too. We could > >>>>>> make that change real fast and then additionally continue to look > >>>>>> at vijava. > >>>>>> > >>>>>> Personal I want to get rid of noredist. If somebody wants to > >>>>>> contribute code that depends on nonfree code, it seems that > >>>>>> should be in a cloudstack-nonfree repo. > >>>>>> > >>>>>> Darren > >>>>>> > >>>>>>> On Sep 22, 2013, at 11:43 PM, Hugo Trippaers <h...@trippaers.nl> > >>>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>>> On Sep 23, 2013, at 1:39 PM, Darren Shepherd > >>>>>>>> <darren.s.sheph...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> Yeah, I'll dig into it more. I think I understand a bit that > >>>>>>>> vmware api is just a bunch of generics objects, so another > >>>>>>>> library on top to create types on top of it helps. So I'll > >>>>>>>> look at it more. In the end I'm still going to probably have > >>>>>>>> reservations about 1) a custom XML/soap framework 2) a third > >>>>>>>> party maintained later between us and vmware (sorta like > >>>>>>>> libvirt-java always behind and incomplete with native libvirt). > >>>>>>>> So it just depends on if the nicer api is worth the risk of the > >>>>>>>> other things. I don't think vmwares api changes much, and you > >>>>>>>> can always get to the generic objects so maybe my concerns are > >>>>>>>> moot. > >>>>>>> > >>>>>>> Thanks, i could actually use a second pair of eyes if we want to > >>>>>>> get this into master. It would be nice to have a few people test > >>>>>>> this. I don't really share the concern on the XML/soap framework > >>>>>>> one is a good or bad as the other usually, i've seen interesting > >>>>>>> things with the axes framework as well. But thats besides the > >>>>>>> point for now. My main objective now it to get vijava working > >>>>>>> with as little changes as possible. Later we can do some > >>>>>>> refactoring and see if vijava really benefits us as much as i > >>>>>>> think/hope it will do. > >>>>>>> > >>>>>>> Your second concern is one i share, we will have to see how it goes. > >>>>>>> Vmware doesn't really change its api that often and if it does > >>>>>>> we are generally not the early adopters of new versions of > >>>>>>> libraries. So for now we should be ok. > >>>>>>> > >>>>>>> Hopefully we will get the vmware stuff in the redistributable > >>>>>>> build which is the primary objective here. All benefits are nice > >>>>>>> to have for future developments. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> Hugo > >>>>>>> > >>>>>>>> > >>>>>>>> Darren > >>>>>>>> > >>>>>>>>> On Sep 22, 2013, at 10:14 PM, Hugo Trippaers > >>>>>>>>> <h...@trippaers.nl> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On Sep 23, 2013, at 1:01 PM, Darren Shepherd > >>>>>>>>>> <darren.s.sheph...@gmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>> Oh, I thought the primary motivation was just to get to fully > >>>>>>>>>> open source and out of noredist. I don't know enough about > >>>>>>>>>> VMware and vijava so my comments may be off base > (everything > >>>>>>>>>> I know about vmware client is based off about 2 hours of > >>>>>>>>>> googling), but my gut reaction is that its better to stick > >>>>>>>>>> with mainstream than use vijava. I understand the VMware > >>>>>>>>>> wsdl is a complicated and weird API. But the fact that you > >>>>>>>>>> could drop vijava in real quick and it mostly matches the > >>>>>>>>>> existing illustrates that its not a big departure from from > >>>>>>>>>> the vmware bindings so doesn't seem to make consuming it > much > >>>>>>>>>> easier. It seems that vijava was better than vmware sdk > >>>>>>>>>> 2.5 > >>>>>>>>>> because you didn't need Apache Axis. But vSphere 5.1 sdk is > >>>>>>>>>> based off of JAXWS and thus doesn't need axis anymore. If > >>>>>>>>>> I'm going to put my trust in something at runtime I'd rather > >>>>>>>>>> use the sun/oracle jaxws or apache CXF and not some custom > >>>>>>>>>> xml/soap framework one guy wrote. > >>>>>>>>> > >>>>>>>>> The drop in real quick bit is just for starters. Some of the > >>>>>>>>> enums have changes names and instead of lists vijava uses > >>>>>>>>> arrays. Those items are pretty quick to adapt. The real > >>>>>>>>> interesting things are in the serviceInstance etc. That's > >>>>>>>>> where there are some changes. A nice example is on the vijava > >>>>>>>>> website where 100 lines of "regular" > >>>>>>>>> vmware > >>>>>>>>> sdk is replaced by 20-something lines of vijava. I'd say dig a > >>>>>>>>> bit deeper and i could use the help with the conversion process. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Additionally, if somebody wants to know how to do something > >>>>>>>>>> with VMware or why something isn't working, I'd rather point > >>>>>>>>>> them to the VMware SDK documentation than vijava. I would > >>>>>>>>>> assume that there is going to be more information about the > >>>>>>>>>> VMware library then there would be for vijava on > >>>>>>>>>> stackoverflow and google in general. > >>>>>>>>> > >>>>>>>>> Google it, so far you are right, but java projects are switching. > >>>>>>>>> Don't forget that vijava is sort of an official vmware > >>>>>>>>> project. It is being maintained by one of their engineers and > >>>>>>>>> actually published in the com.vmware namespace. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Finally, I wouldn't consider us generating and checking in > >>>>>>>>>> the JAXWS bindings as being overhead in maintenance. The > >>>>>>>>>> xapi bindings are not the same thing. VMware API is first > >>>>>>>>>> and foremost a SOAP service. The java bindings they provide > >>>>>>>>>> are just a convenience in that they already generated the > >>>>>>>>>> client stubs for you. But if I was to consume any other SOAP > >>>>>>>>>> service in the world, I would be generating my client stubs > >>>>>>>>>> for it. So this is just the normal approach you take to > >>>>>>>>>> consume a webservice. > >>>>>>>>>> Typically you > >>>>>>>>>> generate the stubs as part of the build and never check-in > >>>>>>>>>> the generated code to git, but I don't think we can check the > >>>>>>>>>> vmware wsdl into git (if we could, that would be ideal). But > >>>>>>>>>> basically, if I'm generating stubs or I'm using a java jar, > >>>>>>>>>> its about the same overhead. If the webservice moves from > >>>>>>>>>> version X, I generate new stubs against version X of the > >>>>>>>>>> wsdl. > >>>>>>>>>> If the > >>>>>>>>>> jar changes to version X, I update the pom dependency to > >>>>>>>>>> version X. > >>>>>>>>>> In > >>>>>>>>>> both cases, you still have to regression test for > >>>>>>>>>> compatibility, so testing effort trumps all other concerns. > >>>>>>>>> > >>>>>>>>> I would seriously consider that overhead in maintenance. Now i > >>>>>>>>> don't even have to worry about that besides 4 lines of > >>>>>>>>> dependency in my maven project. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> So I'd personally like it if we just generated the stubs > >>>>>>>>>> ourself and then we can move VMware plugin out of redist. I > >>>>>>>>>> guess it would be helpful if you could illustrate some of the > >>>>>>>>>> benefits of vijava. I know you wanted to get it working > >>>>>>>>>> first so we could test the merits of it, I'm just having a > >>>>>>>>>> hard time seeing why we would even attempt it, if we can just > >>>>>>>>>> stick basically with what we have today, but make it all open > >>>>>>>>>> source and distributable. > >>>>>>>>> > >>>>>>>>> Stay tuned and follow the commits :-) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Darren > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> > >>>>>>>>> Hugo > >
