[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:
>> [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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]