[libvirt] [libvirt-java] [RFC] simplify java build process
Hi, I have small patch series which tries to accomplish a easier developer experience when building libvirt-java. The reason is simple based on the fact that the following workflow does not work out of the box. 1. with ant: # git clone git://libvirt.org/libvirt-java.git # cd libvirt-java # ant gives: [javac] Compiling 64 source files to /home/stefan/dev/libvirt-java/target/classes [javac] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:5: error: package com.sun.jna does not exist [javac] import com.sun.jna.Native; ... because the ant build depends on a locally installed jna.jar which might be not present. 2. with maven3 # cp pom.xml.in pom.xml # mvn clean install gives: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project libvirt: Compilation failure: Compilation failure: [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/DomainSnapshot.java:[4,7] error: static import declarations are not supported in -source 1.3 because maven still defaults to java source 1.3 on certain distributions (ubuntu 13.04 here). after adding a proper setting with the maven-compiler-plugin i get: [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:[41,28] cannot find symbol symbol: method nativeValue(com.sun.jna.Pointer) location: class com.sun.jna.Pointer [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:[42,16] cannot find symbol symbol: method nativeValue(com.sun.jna.Pointer,long) location: class com.sun.jna.Pointer This is because jna version 3.0.9 is specified but this version does not have these signatures. To make a long story short i would like to propose the following patches: 1. remove the ant components (build.xml, build.properties) altogether and use maven exclusively. 2. rename pom.xml.in into pom.xml and specify java source and jna 3. remove libvirt-java.spec.in and create the libvirt-java.rpm with the rpm-maven-plugin. 4. update the README and INSTALL accordingly As result there will be only one file which is responsible for the build left (pom.xml). If there is a consensus i will post the patches as a followup. Any objections, suggestions ? Greetings -- Stefan Majer
At Tue, 7 May 2013 16:55:06 +0200, Stefan Majer wrote:
after adding a proper setting with the maven-compiler-plugin i get:
[ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:[41,28] cannot find symbol symbol: method nativeValue(com.sun.jna.Pointer) location: class com.sun.jna.Pointer [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:[42,16] cannot find symbol symbol: method nativeValue(com.sun.jna.Pointer,long) location: class com.sun.jna.Pointer
This is because jna version 3.0.9 is specified but this version does not have these signatures.
Yes, JNA 3.3.0 is required as a minimum by libvirt-java. So, as it is now, publishing a new version of libvirt-java to maven would not work / produce a non working artifact because actually a newer JNA would be needed by the code base. Since building is done using a different tool than for publishing, it never turned up to be a problem. (This would probably be another good reason to use a single build tool only, not some awkward combination thereof.)
To make a long story short i would like to propose the following patches:
1. remove the ant components (build.xml, build.properties) altogether and use maven exclusively.
You should also remove findbugs.xml then (using the maven findbugs plugin instead).
2. rename pom.xml.in into pom.xml and specify java source and jna
OK, which version of JNA do we use? 3.3.0 to begin with?
3. remove libvirt-java.spec.in and create the libvirt-java.rpm with the rpm-maven-plugin.
I have no idea / experience about this one. We'll have to see whether this works out for the different distros I think. What about the Debian package build?
4. update the README and INSTALL accordingly
The README should be generated / updated with the correct version number when publishing a source tarball. Apropos publishing: I suppose maven has some kind of scp plugin to copy the different artifacts to the server just like the ant targets "maven", "publish_source", "publish_srpm"?
As result there will be only one file which is responsible for the build left (pom.xml). If there is a consensus i will post the patches as a followup.
Any objections, suggestions ?
+1 for doing the transition from (ant+maven) -> maven. -- AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany Phone: +49 341 265 310 19 Web:<http://www.av-test.org> Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076) Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern
On Wed, May 08, 2013 at 04:11:36PM +0200, Claudio Bley wrote:
3. remove libvirt-java.spec.in and create the libvirt-java.rpm with the rpm-maven-plugin.
I have no idea / experience about this one. We'll have to see whether this works out for the different distros I think.
The libvirt-java.spec.in must follow the Fedora packaging standards for Java apps. So we should keep it and not auto-generate one with maven. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi, On Wed, May 8, 2013 at 4:21 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Wed, May 08, 2013 at 04:11:36PM +0200, Claudio Bley wrote:
3. remove libvirt-java.spec.in and create the libvirt-java.rpm with the rpm-maven-plugin.
I have no idea / experience about this one. We'll have to see whether this works out for the different distros I think.
The libvirt-java.spec.in must follow the Fedora packaging standards for Java apps. So we should keep it and not auto-generate one with maven.
Ok, so i remove the rpm packaging part in my pom.xml and only update the version string in the libvirt-java.spec This is fine as well. Stefan
On Wed, May 8, 2013 at 4:11 PM, Claudio Bley <cbley@av-test.de> wrote:
At Tue, 7 May 2013 16:55:06 +0200, Stefan Majer wrote:
after adding a proper setting with the maven-compiler-plugin i get:
[ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:[41,28] cannot find symbol symbol: method nativeValue(com.sun.jna.Pointer) location: class com.sun.jna.Pointer [ERROR] /home/stefan/dev/libvirt-java/src/main/java/org/libvirt/Library.java:[42,16] cannot find symbol symbol: method nativeValue(com.sun.jna.Pointer,long) location: class com.sun.jna.Pointer
This is because jna version 3.0.9 is specified but this version does not have these signatures.
Yes, JNA 3.3.0 is required as a minimum by libvirt-java.
So, as it is now, publishing a new version of libvirt-java to maven would not work / produce a non working artifact because actually a newer JNA would be needed by the code base.
Since building is done using a different tool than for publishing, it never turned up to be a problem.
(This would probably be another good reason to use a single build tool only, not some awkward combination thereof.)
To make a long story short i would like to propose the following patches:
1. remove the ant components (build.xml, build.properties) altogether and use maven exclusively.
You should also remove findbugs.xml then (using the maven findbugs plugin instead).
Ok, i will check this.
2. rename pom.xml.in into pom.xml and specify java source and jna
OK, which version of JNA do we use? 3.3.0 to begin with?
At the moment i have specified 3.5.1 which is the most actual one.
3. remove libvirt-java.spec.in and create the libvirt-java.rpm with the rpm-maven-plugin.
I have no idea / experience about this one. We'll have to see whether this works out for the different distros I think.
We use this in all of our builds and this creates rpms as long as the rpmbuild binary is installed.
What about the Debian package build?
This is possible as well, but i didnt do that in the past, so i will skip this at first.
4. update the README and INSTALL accordingly
The README should be generated / updated with the correct version number when publishing a source tarball.
I already do this in my tree.
Apropos publishing: I suppose maven has some kind of scp plugin to copy the different artifacts to the server just like the ant targets "maven", "publish_source", "publish_srpm"?
Is this required from the beginning, i have no idea how this works.
As result there will be only one file which is responsible for the build left (pom.xml). If there is a consensus i will post the patches as a followup.
Any objections, suggestions ?
+1 for doing the transition from (ant+maven) -> maven. -- AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany Phone: +49 341 265 310 19 Web:<http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076) Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern
I'm in the process of preparing the patch set and will back here the next few days. Greetings and thanx for commenting -- Stefan Majer
participants (3)
-
Claudio Bley -
Daniel P. Berrange -
Stefan Majer