9:55 a.m.
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
9:11 a.m.
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
9:21 a.m.
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 :|
9:25 a.m.
Hi,
On Wed, May 8, 2013 at 4:21 PM, Daniel P. Berrange <berrange(a)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
9:23 a.m.
On Wed, May 8, 2013 at 4:11 PM, Claudio Bley <cbley(a)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
4216
days inactive
4217
days old
4 comments
3 participants
participants (3)
-
Claudio Bley -
Daniel P. Berrange -
Stefan Majer