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 >
