[libvirt] [libvirt-java] [RFC] simplify java build process

[Stefan Majer]

On Wed, May 8, 2013 at 4:11 PM, Claudio Bley <cbley at 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