Bug#458895: maven2: commons-cli.jar is the culprit
Paul Cager schrieb: Although the change has destroyed backwards compatibility (and I don't like that), the new behaviour agrees with cli's API specification. So I think we should call this a bug in Maven which just happens to be harmless with cli version 1.0. Thanks, Paul, I think that's the way to go. I've seen one of two issues in the Maven JIRA mentioning the transition to common-cli 1.1, but I don't think there was a patch for it, so I assume the Maven developers would welcome the fix. cheers. dalibor topic ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#458895: maven2: commons-cli.jar is the culprit
Paul Cager wrote: Mike Paul wrote: Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 [...] It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. [...] It would seem that this behaviour relies on Maven using an old version of commons-cli. I'll investigate further. [...] I've not had time to fix this problem yet, so I thought I'd just let you know what's happening. The problem happens because of a change introduced in commons-cli 1.1, which is described in http://issues.apache.org/jira/browse/CLI-137 Although the change has destroyed backwards compatibility (and I don't like that), the new behaviour agrees with cli's API specification. So I think we should call this a bug in Maven which just happens to be harmless with cli version 1.0. I'll prepare a new revision of the maven2 Debian package with Maven's calls to commons.cli patched, and send the bug upstream to the Maven developers (although they still use cli version 1.0). It'll probably take a few days as I want to give it a good test. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#458895: maven2: commons-cli.jar is the culprit
Mike Paul wrote: Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 [...] It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. Thanks for investigating this so thoroughly, and sorry I have not had more time to look at it myself. It's a bit odd. At first I thought it must be a bug in the Debian packaging of commons-cli, but I downloaded the official Apache jar from http://mirrors.dedipower.com/ftp.apache.org/commons/cli/binaries/commons-cli-1.1.tar.gz and that exhibits the same failure. If you download the jar from Maven's repo (http://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.jar) then it all works. It would seem that this behaviour relies on Maven using an old version of commons-cli. I'll investigate further. [...] ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#458895: maven2: commons-cli.jar is the culprit
Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 Comparing the Java commands run by Debian's /usr/bin/mvn script and the one in Apache's release, it turns out that the problem occurs if the -Dmaven.home= option is set to /usr/share/maven2, but not if it refers to Apache's distribution. However, if I rearrange the Java command line so that the -DgroupId and -DartifactId commands come *before* the class name (org.codehaus.classworlds.Launcher), then it works even with -Dmaven.home=/usr/share/maven2. When they're given after the class name, they're passed through to the application rather than interpreted by the JVM, so it looks like Apache's version is manually handling -D options given to the application, setting properties as if they'd been given to the JVM, and Debian's version is not. I ran a diff between /usr/share/maven2 and the contents of Apache's Maven distribution, and found that there are a bunch of jars in /usr/share/maven2/lib that aren't in the Apache distribution's lib/ directory. It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. I don't know much about the commons-cli library, but since it does command-line parsing, it stands to reason that it could be what's doing the special handling of -D options given to the application. Apache's Maven distribution includes commons-cli in its maven-2.0.8-uber.jar, which I guess I'm overriding when I copy Debian's commons-cli.jar into the lib/ directory. So, it looks like Debian's commons-cli isn't handling -D options passed to the application like Apache's does. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages maven2 depends on: ii libcommons-cli-java 1.1-1 API for working with the command l ii libdoxia-java1.0-alpha-7-1 a powerful content generation fram ii libjsch-java 0.1.36-1java secure channel ii libjtidy-java7+svn20070309-1 a Java port of HTML Tidy, a HTML s ii libplexus-interactivity- 1.0-alpha-6-2 interactivity API for the Plexus f ii libplexus-utils-java 1:1.4.8-1 utilities for the Plexus framework ii libwagon-java1.0-beta-2-2tools to manage Maven artifacts an ii libxalan2-java 2.7.1-1 XSL Transformations (XSLT) process maven2 recommends no packages. -- no debconf information ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
