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.
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 >
