[libvirt] Can I request a new release of libvirt-java?
Hello, In the recent months various new methods were added to libvirt-java which we (Apache CloudStack) would like to use in our KVM code. For example resizing storage volumes, right now we have to do this with Bash scripting since although libvirt supports resizing volumes, the current release (0.4.9) of libvirt-java doesn't. I don't know if there are any objections, but if possible I'd like to see 0.5.0 released so we get this new functionality for CloudStack. We use maven for building CloudStack and it fetches libvirt-java from libvirt.org/maven2 Thank you, Wido den Hollander
On 08/15/2013 11:00 AM, Wido den Hollander wrote:
Hello,
In the recent months various new methods were added to libvirt-java which we (Apache CloudStack) would like to use in our KVM code.
For example resizing storage volumes, right now we have to do this with Bash scripting since although libvirt supports resizing volumes, the current release (0.4.9) of libvirt-java doesn't.
I don't know if there are any objections, but if possible I'd like to see 0.5.0 released so we get this new functionality for CloudStack.
We use maven for building CloudStack and it fetches libvirt-java from libvirt.org/maven2
Can I give this one a small bump? Wido
Thank you,
Wido den Hollander
On Fri, Aug 30, 2013 at 12:31:55PM +0200, Wido den Hollander wrote:
On 08/15/2013 11:00 AM, Wido den Hollander wrote:
Hello,
In the recent months various new methods were added to libvirt-java which we (Apache CloudStack) would like to use in our KVM code.
For example resizing storage volumes, right now we have to do this with Bash scripting since although libvirt supports resizing volumes, the current release (0.4.9) of libvirt-java doesn't.
I don't know if there are any objections, but if possible I'd like to see 0.5.0 released so we get this new functionality for CloudStack.
We use maven for building CloudStack and it fetches libvirt-java from libvirt.org/maven2
Can I give this one a small bump?
Oops, okay, point taken, not sure i can do this today, but I will try this week ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Sep 02, 2013 at 08:14:33AM +0800, Daniel Veillard wrote:
On Fri, Aug 30, 2013 at 12:31:55PM +0200, Wido den Hollander wrote:
On 08/15/2013 11:00 AM, Wido den Hollander wrote:
Hello,
In the recent months various new methods were added to libvirt-java which we (Apache CloudStack) would like to use in our KVM code.
For example resizing storage volumes, right now we have to do this with Bash scripting since although libvirt supports resizing volumes, the current release (0.4.9) of libvirt-java doesn't.
I don't know if there are any objections, but if possible I'd like to see 0.5.0 released so we get this new functionality for CloudStack.
We use maven for building CloudStack and it fetches libvirt-java from libvirt.org/maven2
Can I give this one a small bump?
Oops, okay, point taken, not sure i can do this today, but I will try this week !
Hi Wido, I tried to do this today, but I hit a problem, when I run ./autobuild.sh on fedora-19 it starts to build goes fine, was failing in rpm due to broken (fixed in git now), but for some reason it does not produce target/libvirt-0.5.0.jar (after fixing the build version to be 0.5.0) it does build target/libvirt-java-0.5.0.tar.gz target/libvirt-0.5.0-javadoc.jar and target/libvirt-0.5.0-sources.jar but not the binary jar. But it does seems to compile correctly: ------------- .... [javac] Compiling 64 source files to /home/veillard/rpms/BUILD/libvirt-java-0.5.0/target/classes init: [copy] Copying 1 file to /home/veillard/rpms/BUILD/libvirt-java-0.5.0 build: docs: [mkdir] Created dir: /home/veillard/rpms/BUILD/libvirt-java-0.5.0/target/javadoc [javadoc] Generating Javadoc ... BUILD SUCCESSFUL Total time: 5 seconds + exit 0 .... --------------- I'm puzzled, how can the build be successful if the main jar is not generated ??? Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 09/13/2013 10:29 AM, Daniel Veillard wrote:
On Mon, Sep 02, 2013 at 08:14:33AM +0800, Daniel Veillard wrote:
On Fri, Aug 30, 2013 at 12:31:55PM +0200, Wido den Hollander wrote:
On 08/15/2013 11:00 AM, Wido den Hollander wrote:
Hello,
In the recent months various new methods were added to libvirt-java which we (Apache CloudStack) would like to use in our KVM code.
For example resizing storage volumes, right now we have to do this with Bash scripting since although libvirt supports resizing volumes, the current release (0.4.9) of libvirt-java doesn't.
I don't know if there are any objections, but if possible I'd like to see 0.5.0 released so we get this new functionality for CloudStack.
We use maven for building CloudStack and it fetches libvirt-java from libvirt.org/maven2
Can I give this one a small bump?
Oops, okay, point taken, not sure i can do this today, but I will try this week !
Hi Wido,
I tried to do this today, but I hit a problem, when I run ./autobuild.sh on fedora-19 it starts to build goes fine, was failing in rpm due to broken (fixed in git now), but for some reason it does not produce target/libvirt-0.5.0.jar (after fixing the build version to be 0.5.0) it does build target/libvirt-java-0.5.0.tar.gz target/libvirt-0.5.0-javadoc.jar and target/libvirt-0.5.0-sources.jar but not the binary jar. But it does seems to compile correctly:
------------- .... [javac] Compiling 64 source files to /home/veillard/rpms/BUILD/libvirt-java-0.5.0/target/classes
init: [copy] Copying 1 file to /home/veillard/rpms/BUILD/libvirt-java-0.5.0
build: docs: [mkdir] Created dir: /home/veillard/rpms/BUILD/libvirt-java-0.5.0/target/javadoc [javadoc] Generating Javadoc ... BUILD SUCCESSFUL Total time: 5 seconds + exit 0 .... ---------------
I'm puzzled, how can the build be successful if the main jar is not generated ???
Odd, I tried building the Deb and that works fine: wido@wido-laptop:~/repos/libvirt-java$ ant deb Buildfile: /home/wido/repos/libvirt-java/build.xml init: [mkdir] Created dir: /home/wido/repos/libvirt-java/target/classes [mkdir] Created dir: /home/wido/repos/libvirt-java/target/testclasses [mkdir] Created dir: /home/wido/repos/libvirt-java/target/cache [copy] Copying 1 file to /home/wido/repos/libvirt-java build: [javac] Compiling 64 source files to /home/wido/repos/libvirt-java/target/classes jar: [jar] Building jar: /home/wido/repos/libvirt-java/target/libvirt-0.5.0.jar deb: [mkdir] Created dir: /home/wido/repos/libvirt-java/target/libvirt-java/DEBIAN [copy] Copying 1 file to /home/wido/repos/libvirt-java/target/libvirt-java/DEBIAN [mkdir] Created dir: /home/wido/repos/libvirt-java/target/libvirt-java/usr/share/java [copy] Copying 1 file to /home/wido/repos/libvirt-java/target/libvirt-java/usr/share/java [exec] dpkg-deb: building package `libvirt-java' in `target/libvirt-java_0.5.0_all.deb'. BUILD SUCCESSFUL Total time: 3 seconds wido@wido-laptop:~/repos/libvirt-java$ The problem with the RPM seems to be it executes "ant build docs" While "build" actually builds the classes, it doesn't generate a JAR file. It should run: $ ant jar docs That produces the correct .jar file in the target directory. Wido
Daniel
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
On 09/13/2013 10:29 AM, Daniel Veillard wrote:
[...]
I'm puzzled, how can the build be successful if the main jar is not generated ???
Odd, I tried building the Deb and that works fine:
wido@wido-laptop:~/repos/libvirt-java$ ant deb Buildfile: /home/wido/repos/libvirt-java/build.xml
init: [mkdir] Created dir: /home/wido/repos/libvirt-java/target/classes [mkdir] Created dir: /home/wido/repos/libvirt-java/target/testclasses [mkdir] Created dir: /home/wido/repos/libvirt-java/target/cache [copy] Copying 1 file to /home/wido/repos/libvirt-java
build: [javac] Compiling 64 source files to /home/wido/repos/libvirt-java/target/classes
jar: [jar] Building jar: /home/wido/repos/libvirt-java/target/libvirt-0.5.0.jar
deb: [mkdir] Created dir: /home/wido/repos/libvirt-java/target/libvirt-java/DEBIAN [copy] Copying 1 file to /home/wido/repos/libvirt-java/target/libvirt-java/DEBIAN [mkdir] Created dir: /home/wido/repos/libvirt-java/target/libvirt-java/usr/share/java [copy] Copying 1 file to /home/wido/repos/libvirt-java/target/libvirt-java/usr/share/java [exec] dpkg-deb: building package `libvirt-java' in `target/libvirt-java_0.5.0_all.deb'.
BUILD SUCCESSFUL Total time: 3 seconds wido@wido-laptop:~/repos/libvirt-java$
The problem with the RPM seems to be it executes "ant build docs"
While "build" actually builds the classes, it doesn't generate a JAR file.
It should run:
$ ant jar docs
That produces the correct .jar file in the target directory.
Indeed that was the problem, I just commited the fix, thanks ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 09/13/2013 11:26 AM, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
On 09/13/2013 10:29 AM, Daniel Veillard wrote:
[...]
I'm puzzled, how can the build be successful if the main jar is not generated ???
Odd, I tried building the Deb and that works fine:
wido@wido-laptop:~/repos/libvirt-java$ ant deb Buildfile: /home/wido/repos/libvirt-java/build.xml
init: [mkdir] Created dir: /home/wido/repos/libvirt-java/target/classes [mkdir] Created dir: /home/wido/repos/libvirt-java/target/testclasses [mkdir] Created dir: /home/wido/repos/libvirt-java/target/cache [copy] Copying 1 file to /home/wido/repos/libvirt-java
build: [javac] Compiling 64 source files to /home/wido/repos/libvirt-java/target/classes
jar: [jar] Building jar: /home/wido/repos/libvirt-java/target/libvirt-0.5.0.jar
deb: [mkdir] Created dir: /home/wido/repos/libvirt-java/target/libvirt-java/DEBIAN [copy] Copying 1 file to /home/wido/repos/libvirt-java/target/libvirt-java/DEBIAN [mkdir] Created dir: /home/wido/repos/libvirt-java/target/libvirt-java/usr/share/java [copy] Copying 1 file to /home/wido/repos/libvirt-java/target/libvirt-java/usr/share/java [exec] dpkg-deb: building package `libvirt-java' in `target/libvirt-java_0.5.0_all.deb'.
BUILD SUCCESSFUL Total time: 3 seconds wido@wido-laptop:~/repos/libvirt-java$
The problem with the RPM seems to be it executes "ant build docs"
While "build" actually builds the classes, it doesn't generate a JAR file.
It should run:
$ ant jar docs
That produces the correct .jar file in the target directory.
Indeed that was the problem, I just commited the fix, thanks !
Great! I see you tagged the 0.5.0 release. Could you also upload the files here: http://www.libvirt.org/maven2/org/libvirt/libvirt/ That way we can use Maven in CloudStack to depend on libvirt-java 0.5.0 Wido
Daniel
Raising this due to maven On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
[...]
Indeed that was the problem, I just commited the fix, thanks !
Hum, getting back on-list, I pushed everything including maven files at their location, unfortunately this never shows up in repos Seems that to be indexed one need to push to an expernal repo within that small list: "Instead of maintaining repository rsync feeds for each projects, we now encourage projects to use an approved repository hosting location. Currently approved repository hosting locations: Apache Software Foundation (for all Apache projects) Codehaus (for Codehaus projects) FuseSource Forge (focused on FUSE related projects) Nuiton.org " We are definitely not Apache Software Foundation, nor Codehaus, nor FuseSource, and I have no idea what Nuiton.org might be nor intent to push to a random place. http://maven.apache.org/guides/mini/guide-central-repository-upload.html " Explanations Having each project maintain its own repository with rsync to Central Repository used to be the preferred process until January 2010. But we are no longer accepting rsync requests on a per project basis. Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone. The aggregation of projects into single larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone." As a result current repos only list libvirt-java up to 0.4.7 and none of the newer versions. Repository are evil, and they built a solution based on those. The bug is on their side, I won't upload to $random_site, so unless someone else pulls from libvirt.org, libvirt-java maven won't index more recent build. Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 09/16/2013 07:58 AM, Daniel Veillard wrote:
Raising this due to maven
On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
[...]
Indeed that was the problem, I just commited the fix, thanks !
Hum, getting back on-list, I pushed everything including maven files at their location, unfortunately this never shows up in repos
Seems that to be indexed one need to push to an expernal repo within that small list:
I had this discussion last year as well with somebody else from RedHat and we ended up the the conclusion that libvirt-java wouldn't go to Maven Central. In the CloudStack project we simply added libvirt.org as a extra repository: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=plugins/hy... I also just tried libvirt-java 0.5.0, it works for what we are using :) Wido
"Instead of maintaining repository rsync feeds for each projects, we now encourage projects to use an approved repository hosting location.
Currently approved repository hosting locations:
Apache Software Foundation (for all Apache projects) Codehaus (for Codehaus projects) FuseSource Forge (focused on FUSE related projects) Nuiton.org "
We are definitely not Apache Software Foundation, nor Codehaus, nor FuseSource, and I have no idea what Nuiton.org might be nor intent to push to a random place.
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
" Explanations
Having each project maintain its own repository with rsync to Central Repository used to be the preferred process until January 2010. But we are no longer accepting rsync requests on a per project basis.
Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone.
The aggregation of projects into single larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone."
As a result current repos only list libvirt-java up to 0.4.7 and none of the newer versions.
Repository are evil, and they built a solution based on those. The bug is on their side, I won't upload to $random_site, so unless someone else pulls from libvirt.org, libvirt-java maven won't index more recent build.
Daniel
On 09/16/2013 07:58 AM, Daniel Veillard wrote:
Raising this due to maven
On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
[...]
Indeed that was the problem, I just commited the fix, thanks !
Somewhat related to this: It seems you have compiled with Java 7 causing the bindings not to work with Java 6. A lot of users are still running Java 6 on their systems. You could do this with in build.xml: <javac target="1.6" .../> Or something like: <property name="javac.target" value="1.6" /> .. <javac target="${javac.target}" .../> Java 6 is still around and I think it should be supported for older platforms. Wido
Hum, getting back on-list, I pushed everything including maven files at their location, unfortunately this never shows up in repos
Seems that to be indexed one need to push to an expernal repo within that small list:
"Instead of maintaining repository rsync feeds for each projects, we now encourage projects to use an approved repository hosting location.
Currently approved repository hosting locations:
Apache Software Foundation (for all Apache projects) Codehaus (for Codehaus projects) FuseSource Forge (focused on FUSE related projects) Nuiton.org "
We are definitely not Apache Software Foundation, nor Codehaus, nor FuseSource, and I have no idea what Nuiton.org might be nor intent to push to a random place.
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
" Explanations
Having each project maintain its own repository with rsync to Central Repository used to be the preferred process until January 2010. But we are no longer accepting rsync requests on a per project basis.
Over time, we have learned that this process is not scalable. Many of the projects being synced release very infrequently, yet we have to hit hundreds of servers several times a day looking for artifacts that don't change. Additionally, there is no good mechanism currently for validating the incoming data via the rsync, and this leads to bad metadata that affects everyone.
The aggregation of projects into single larger feeds allows us to sync faster and more often, and ensuring these locations perform sufficient checks increases the quality of metadata for everyone."
As a result current repos only list libvirt-java up to 0.4.7 and none of the newer versions.
Repository are evil, and they built a solution based on those. The bug is on their side, I won't upload to $random_site, so unless someone else pulls from libvirt.org, libvirt-java maven won't index more recent build.
Daniel
On Tue, Sep 17, 2013 at 09:04:46AM +0200, Wido den Hollander wrote:
On 09/16/2013 07:58 AM, Daniel Veillard wrote:
Raising this due to maven
On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
[...]
Indeed that was the problem, I just commited the fix, thanks !
Somewhat related to this: It seems you have compiled with Java 7 causing the bindings not to work with Java 6.
A lot of users are still running Java 6 on their systems.
You could do this with in build.xml:
<javac target="1.6" .../>
Or something like:
<property name="javac.target" value="1.6" /> .. <javac target="${javac.target}" .../>
Java 6 is still around and I think it should be supported for older platforms.
I just compiled with the java available in my system (fedora 19). Do one really need to release for every version of java potentially using libvirt-java ? Can't they just rebuild locally too ? I take patches :-) as build.xml is in git Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 09/17/2013 09:23 AM, Daniel Veillard wrote:
On Tue, Sep 17, 2013 at 09:04:46AM +0200, Wido den Hollander wrote:
On 09/16/2013 07:58 AM, Daniel Veillard wrote:
Raising this due to maven
On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
[...]
Indeed that was the problem, I just commited the fix, thanks !
Somewhat related to this: It seems you have compiled with Java 7 causing the bindings not to work with Java 6.
A lot of users are still running Java 6 on their systems.
You could do this with in build.xml:
<javac target="1.6" .../>
Or something like:
<property name="javac.target" value="1.6" /> .. <javac target="${javac.target}" .../>
Java 6 is still around and I think it should be supported for older platforms.
I just compiled with the java available in my system (fedora 19). Do one really need to release for every version of java potentially using libvirt-java ? Can't they just rebuild locally too ?
Sure, but if the code in libvirt.org/maven2 is Java 1.7 systems building with Maven and using Java 1.6 can't use it. There is no special code in libvirt-java which requires Java 1.7 to operate. By setting the source and target version to 1.6 the code will run on at least 1.6, but will work just fine on 1.7 systems. It's mainly a compatibility thing.
I take patches :-) as build.xml is in git
Just sent a patch :) Wido
Daniel
On Tue, Sep 17, 2013 at 10:09:36AM +0200, Wido den Hollander wrote:
On 09/17/2013 09:23 AM, Daniel Veillard wrote:
On Tue, Sep 17, 2013 at 09:04:46AM +0200, Wido den Hollander wrote:
On 09/16/2013 07:58 AM, Daniel Veillard wrote:
Raising this due to maven
On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote:
[...]
Indeed that was the problem, I just commited the fix, thanks !
Somewhat related to this: It seems you have compiled with Java 7 causing the bindings not to work with Java 6.
A lot of users are still running Java 6 on their systems.
You could do this with in build.xml:
<javac target="1.6" .../>
Or something like:
<property name="javac.target" value="1.6" /> .. <javac target="${javac.target}" .../>
Java 6 is still around and I think it should be supported for older platforms.
I just compiled with the java available in my system (fedora 19). Do one really need to release for every version of java potentially using libvirt-java ? Can't they just rebuild locally too ?
Sure, but if the code in libvirt.org/maven2 is Java 1.7 systems building with Maven and using Java 1.6 can't use it.
There is no special code in libvirt-java which requires Java 1.7 to operate.
By setting the source and target version to 1.6 the code will run on at least 1.6, but will work just fine on 1.7 systems.
It's mainly a compatibility thing.
Okay, let's just assume i know absolutely nothing about Java use in practice :-)
I take patches :-) as build.xml is in git
Just sent a patch :)
ACK'ed i think you can push, right ? Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 09/17/2013 11:13 AM, Daniel Veillard wrote:
On Tue, Sep 17, 2013 at 10:09:36AM +0200, Wido den Hollander wrote:
On 09/17/2013 09:23 AM, Daniel Veillard wrote:
On Tue, Sep 17, 2013 at 09:04:46AM +0200, Wido den Hollander wrote:
On 09/16/2013 07:58 AM, Daniel Veillard wrote:
Raising this due to maven
On Fri, Sep 13, 2013 at 05:26:24PM +0800, Daniel Veillard wrote:
On Fri, Sep 13, 2013 at 11:13:53AM +0200, Wido den Hollander wrote: > > [...]
Indeed that was the problem, I just commited the fix, thanks !
Somewhat related to this: It seems you have compiled with Java 7 causing the bindings not to work with Java 6.
A lot of users are still running Java 6 on their systems.
You could do this with in build.xml:
<javac target="1.6" .../>
Or something like:
<property name="javac.target" value="1.6" /> .. <javac target="${javac.target}" .../>
Java 6 is still around and I think it should be supported for older platforms.
I just compiled with the java available in my system (fedora 19). Do one really need to release for every version of java potentially using libvirt-java ? Can't they just rebuild locally too ?
Sure, but if the code in libvirt.org/maven2 is Java 1.7 systems building with Maven and using Java 1.6 can't use it.
There is no special code in libvirt-java which requires Java 1.7 to operate.
By setting the source and target version to 1.6 the code will run on at least 1.6, but will work just fine on 1.7 systems.
It's mainly a compatibility thing.
Okay, let's just assume i know absolutely nothing about Java use in practice :-)
No problem! But the current situation is that the 0.5.0 version out there only works with Java 7. Maybe release a 0.5.1 which is compiled for Java 1.6?
I take patches :-) as build.xml is in git
Just sent a patch :)
ACK'ed i think you can push, right ?
I don't have push permissions on the libvirt-java repo. Wido
Daniel
On Tue, Sep 17, 2013 at 11:58:36AM +0200, Wido den Hollander wrote:
On 09/17/2013 11:13 AM, Daniel Veillard wrote:
On Tue, Sep 17, 2013 at 10:09:36AM +0200, Wido den Hollander wrote:
On 09/17/2013 09:23 AM, Daniel Veillard wrote: [...]
I just compiled with the java available in my system (fedora 19). Do one really need to release for every version of java potentially using libvirt-java ? Can't they just rebuild locally too ?
Sure, but if the code in libvirt.org/maven2 is Java 1.7 systems building with Maven and using Java 1.6 can't use it.
There is no special code in libvirt-java which requires Java 1.7 to operate.
By setting the source and target version to 1.6 the code will run on at least 1.6, but will work just fine on 1.7 systems.
It's mainly a compatibility thing.
Okay, let's just assume i know absolutely nothing about Java use in practice :-)
No problem! But the current situation is that the 0.5.0 version out there only works with Java 7.
Maybe release a 0.5.1 which is compiled for Java 1.6?
Can we get a bit more feedback on 0.5.0 before fixing with 0.5.1 ?
I take patches :-) as build.xml is in git
Just sent a patch :)
ACK'ed i think you can push, right ?
I don't have push permissions on the libvirt-java repo.
Hum, need to think about this, Claudio can, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (2)
-
Daniel Veillard -
Wido den Hollander