Agree. Given current CloudStack code base changing something to another thing is really not a good way. As Darren is working on modular spring, why not construct a new VMWare plugin separately using vijava? Then we can reduce the risk of surprising existing customer and switch to new module when it finally gets mature.
> -----Original Message----- > From: Kelven Yang [mailto:kelven.y...@citrix.com] > Sent: Tuesday, September 24, 2013 11:59 AM > To: dev@cloudstack.apache.org > Subject: Re: VmWare SDK to vijava > > 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 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 > >>>>> > >>> > >> > >
