I created a branch vmwware-wsdl at https://github.com/ibuildthecloud/cloudstack.git, and yes I did spell vmware wrong in the branch name. I also created https://reviews.apache.org/r/14304/
Darren On Mon, Sep 23, 2013 at 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 >>>>> >>> >> >
