Darren, you can probably work with Prussians to get it through the bvt suite. That would be a nice start.
Cheers, Hugo Sent from my iPhone > On 25 sep. 2013, at 09:06, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > > 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 >>
