Description of problem: When multiple -D options are given to maven, it interprets the second one as the name of the goal. This breaks the mvn-jpp script, which supplies three -D options. Put the following content into pom.xml in an empty directory: <?xml version="1.0" encoding="UTF-8"?> <project> <modelVersion>4.0.0</modelVersion> <groupId>test</groupId> <artifactId>test</artifactId> <name>Test</name> <version>1.0.0</version> </project> In Fedora 10, invoking "mvn -Dsome.property=foo -Dother.property=bar compile" simply evokes a message that there is nothing to compile. In Rawhide, the same invocation produces this message: [INFO] Invalid task 'other.property=bar': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal This means that no maven-using projects can currently be built in Rawhide, as mvn-jpp always evokes a message of that form. Version-Release number of selected component (if applicable): maven2-2.0.4-10.15.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. See above Actual results: A failed build Expected results: A successful build Additional info:
I have tracked this down to the jakarta-commons-cli 1.0 -> 1.1 update in rawhide. Thanks for filing this. Looking into a fix now...
I didn't realize that jakarta-commons-cli-1.1 was heading for F-10, or I would have given it negative karma. It landed today, and now maven is broken on F-10, too. Having maven broken in Rawhide is one thing, but now I can't build my projects at work on my F-10 box. Is there anything I can do to help find a solution to this problem?
(In reply to comment #1) > I have tracked this down to the jakarta-commons-cli 1.0 -> 1.1 update in > rawhide. Thanks for filing this. Looking into a fix now... I am not familiar with Java (watching this bug because a package I reviewed are now affected by this), however it seems that jakarta-commons-cli 1.1 seems "broken" [1] Debian maven2 maintainer applied a patch for maven2 for this issue [2] , however it seems that the patch just created another problem [3] It seems that for now reverting jakarta-commons-cli to 1.1 is the best solution [1] http://issues.apache.org/jira/browse/CLI-137 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458895 [3] http://jira.codehaus.org/browse/MNG-3356 CCing to jakarta-commons-cli maintainer.
(In reply to comment #3) > It seems that for now reverting jakarta-commons-cli to 1.1 > is the best solution s|to 1.1|to 1.0|
unfortunately, it was updated to 1.1 because some other packages are now requiring it. Reverting really is not the solution.
can someone who is having issue with this (I dont have anything that uses maven) try this http://koji.fedoraproject.org/koji/taskinfo?taskID=1106383 it uses the commons-cli-1.2-SNAPSHOT, which this is suppose to be fixed in.
Created attachment 331094 [details] mock build log of javassist (In reply to comment #6) > can someone who is having issue with this (I dont have anything that uses > maven) try this http://koji.fedoraproject.org/koji/taskinfo?taskID=1106383 it > uses the commons-cli-1.2-SNAPSHOT, which this is suppose to be fixed in. I am not familiar with maven2, however at least javassist (using maven2 to create .pom file) now builds successfully with mockbuild (please see attached)
By the way for srpm using snapshot tarball the versioning needs fixing, however that is another issue.
yes I know, I was just hacking something together to test that version, I will try and package it up nicely tonight.
Correct, the patch mentioned in comment 3 does work. I tried it last week and it fixed the issue. I have been waiting for a reply from the patch author before applying it verbatim in Fedora, but haven't heard anything yet. Anyway, given Debian's license, I am sure it is okay to apply it into Fedora so we should just go ahead and do so.
Fixing component.
Just to be clear, the patch I tried, that works, is MultiOptions.patch from here: http://svn.debian.org/wsvn/pkg-java/trunk/libcommons-cli-java/debian/patches/MultOptions.patch?op=file&rev=0&sc=0 After that patch was applied, I had to make a minor update to maven to make it use hasArgs(1) instead of hasArg() Mamoru, did you check if both mvn and mvn-jpp work, or just one of the two? In my case, one worked, one didn't (until I update maven and rebuilt it ... I forget which one worked and which one didn't though)
(In reply to comment #12) > Mamoru, did you check if both mvn and mvn-jpp work, or just one of the two? In > my case, one worked, one didn't (until I update maven and rebuilt it ... I > forget which one worked and which one didn't though) I just checked if javassist srpm can rebuild with commons-cli 1.2 svn (srpm supplied by Brennan). It seems that javassist srpm uses mvn-jpp.
Just to clarify, we are just going to patch the 1.1 version, and not move to the 1.2 snapshot? If so, I wont bother finishing that package (it has to be patched a little to work with fedoras java to pass self tests).
Are there ay news on this?
I'll be working on this tomorrow.
So it's 10 days later, making the 24th day of maven not working in F-10. All maven-using packages just failed the mass rebuild. Some upgrades I need to get new packages into Fedora are blocked because of this bug. How much longer do you expect it to take to get this bug fixed? At what point will you revert jakarta-commons-cli until a fix can be identified?
Just to summarize: This is an cmopat issue between cli 1.0 and 1.1. As discussed in: http://issues.apache.org/jira/browse/CLI-137?focusedCommentId=12632921#action_12632921 This compatibility to the 1.0 sematics is brought back to us in some 1.2-SNAPSHOT (as mentioned before). So we might consider shiping 1.0 as an extra package and use it for all broken builds or use soem 1.2-SNAPSHOT.
jakarta-commons-cli has been updated in both, F-10 and rawhide now, and it applies the MultiOption patch. Rebuild of maven failed yesterday due to an issue with the new gcj in rawhide though. We (the Java team) need to look into that though. Assigning this issue back to myself.
I had initially thought that a Maven rebuild was necessary with a small patch, to make it work with the patched cli. However, that does not appear to be the case any more. I just tried a build in rawhide with the existing maven and it worked (http://koji.fedoraproject.org/koji/taskinfo?taskID=1209347). So while maven rebuild itself is broken, there is nothing preventing other packages that utilize maven, from building. I am therefore closing this issue. We'll continue to try and get maven rebuilding asap.
jakarta-commons-cli-1.1-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/jakarta-commons-cli-1.1-2.fc10
jakarta-commons-cli-1.1-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.