On Mon, Jul 07, 2008 at 01:14:40PM +0200, Tóth István wrote:
Daniel Veillard wrote:
Ah, okay.... Well my perspective is that libvirt-java should include only parts which are directly releated to using libvirt on Java. I would really not try to reinvent or push any XML related APIs there, at least as part of libvirt bindings (I still have the scars from libxml2, believe me you don't want to push new XML APIs to programmers even specialized ones).
My thoughts exactly.
Okay seems we agree on the fundamentals :-)
But things like the XSD descriptiond might be useful generally, and IMHO are very tied to libvirt, so i think they are a good fit.
Absolutely. I've had major problems when I tried to use some Java XML mapping libraries, because they can only process xsd, and not the language you use. So having high-quality xsd definitions is high on my personal wish-list.
Okay
Also fitting into this model are build makefiles for other environment, I understand that for most Java developpers, configure and make are really foreign tools, so adding ant/Eclipse/... build recipes for the package also makes a lot of sense.
Well, they certainly wouldn't hurt, but I don't see that as a priority. Java-only programmers (end users) won't touch the JNI core parts. They will just install the package, and get on with using it, by adding the jar to their devel enviroment, and perhaps the JNI lib file to the command line.
These kind of users don't really care about the java-libvirt build environment.
okay, so just the Jar availability is sufficient for them, okidoc.
If you want to do something more interesting than renaming the java classes and methods, the you have to hit the JNI bindings, and that code is so ugly, that no-one without some C experience will want to touch it.
Having said that, I think that an ant build file would be the most useful, as it can be used directly in all major development enviroments. There is also this maven thing, that seems to be widely used, but I still haven't figured out exactly what that is :-)
me either, though there are examples in the Fedora-java packaging pages. [...]
My current plans for java-libvirt are:
1. Add the storage API: It's really mostly just copy-paste-search replace but it still takes some work
okay
2. There are some consistency problems with the naming of classes and methods. I'd like to revisit the java api, and make some changes in names, and maybe class structure
Hum, better done early than late. Basically i would prefer to avoid pushing incompatible changes. what kind of inconsistencies problems ?
3. There are many places where the C part leaks memory, this should also be audited/ fixed.
Ah, okay I will have to reread the bindings code then. Not sure how to track leaks, I doubt valgrind can work with java ...
Number 2 is what worries me, I don't know if it's a good idea to push toFedora, when I know I want to make incompatible API changes soon.
yes, which is why I would like to know a bit better :-)
(Or you can just say that you won't accept them, but I'm a big fan of clean and consistent APIs, and the current one can be improved) I believe that I will get around to doing 1. and 2. at least in late july/early august, It's about a three day job, I just don't have that three days right now :-(
Maybe if you can expose what you think is wrong i can try to clean things up. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/