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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list