[jira] (WAGON-411) Enhance merge-maven-repos to work with SNAPSHOT builds
[
https://jira.codehaus.org/browse/WAGON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341856#comment-341856
]
Dan Tran commented on WAGON-411:
Hi Karl, could you move this issue back to MOJO? Thanks
> Enhance merge-maven-repos to work with SNAPSHOT builds
> --
>
> Key: WAGON-411
> URL: https://jira.codehaus.org/browse/WAGON-411
> Project: Maven Wagon
> Issue Type: Improvement
>Affects Versions: 1.0-beta-3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 02:44:56-0600)
> Maven home: D:\maven\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: D:\j2sdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Jim McCaskey
>
> According to Dan Tran the merge-maven-repos goal does not work with
> SNAPSHOTS. I could not find an issue open for that so here we go.
> Here is a link to my original e-mail with Dan's response.
> http://mail-archives.apache.org/mod_mbox/maven-users/201303.mbox/%3CCAPCjjnGNu2%3DV0ZZ4_tT8%2B-4O0Uq%3DmnD8spE5LSLLEdYD7agU_A%40mail.gmail.com%3E
> FWIW, it appears to me that there is a problem with the maven-metadata.xml
> files that get merged. Here is an example of a badly merged file.
> {code}
>
>
> myGroup
> MyArtifact
> 10.2.6-SNAPSHOT
>
>
> 20130313.165705
> 1
>
> 20130313165705
>
>
> MyClassifier
> zip
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
> pom
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-176) upgrade to last 5.0.5
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPMD-176. - Resolution: Fixed done > upgrade to last 5.0.5 > - > > Key: MPMD-176 > URL: https://jira.codehaus.org/browse/MPMD-176 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > > need a workaround to a PMD bug. > see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-182) upgrade to last 5.1.0
Olivier Lamy created MPMD-182: - Summary: upgrade to last 5.1.0 Key: MPMD-182 URL: https://jira.codehaus.org/browse/MPMD-182 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Olivier Lamy -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-176) upgrade to last 5.0.5
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MPMD-176: -- Summary: upgrade to last 5.0.5 (was: upgrade to last 5.1.0) > upgrade to last 5.0.5 > - > > Key: MPMD-176 > URL: https://jira.codehaus.org/browse/MPMD-176 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > > need a workaround to a PMD bug. > see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-176) upgrade to last 5.1.0
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341853#comment-341853 ] Olivier Lamy commented on MPMD-176: --- hehe even if I found weird to still support 1.5 in 2014!! I found it a good plan :-) > upgrade to last 5.1.0 > - > > Key: MPMD-176 > URL: https://jira.codehaus.org/browse/MPMD-176 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > > need a workaround to a PMD bug. > see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-205) NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression
[ https://jira.codehaus.org/browse/MCHECKSTYLE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-205. --- Resolution: Fixed Fix Version/s: 2.12 Assignee: Dennis Lundberg Patch applied in [r1570752|http://svn.apache.org/viewvc?view=revision&revision=1570752]. Many thanks! > NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression > --- > > Key: MCHECKSTYLE-205 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-205 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11 > Environment: maven-checkstyle-plugin v2.11 and 2.12-SNAPSHOT (as of > 12/5/13). Windows 7, JDK7.45 64 bit, maven 3.1 >Reporter: Bob Fields >Assignee: Dennis Lundberg > Fix For: 2.12 > > Attachments: CheckstyleResults.java.patch > > > This worked in release 2.10, no longer works in 2.11. Running mvn site > against a large project with a parent pom with many subprojects (though no > code in the parent project) (andromda v3.5-SNAPSHOT, from sourceforge). Maven > output: > [INFO] Generating "Checkstyle" report--- > maven-checkstyle-plugin:2.12-SNAPSHOT > [INFO] Starting audit... > ... About 6000 files ... > Audit done. > [INFO] There are 4777 checkstyle errors. > And no additional troubleshooting information, even in debug mode ... > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project > andromda: Execution default-site of goal > org.apache.maven.plugins:maven-site-plugin:3.3:site failed. > NullPointerException -> [Help 1] > Caused by: java.lang.NullPointerException > at java.lang.String.compareTo(String.java:1139) > at java.lang.String.compareTo(String.java:108) > at > java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:290) > at java.util.ComparableTimSort.sort(ComparableTimSort.java:171) > at java.util.ComparableTimSort.sort(ComparableTimSort.java:146) > at java.util.Arrays.sort(Arrays.java:472) > at java.util.Collections.sort(Collections.java:155) > at > org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.doFilesSummary(CheckstyleReportGenerator.java:654) > at > org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.generateReport(CheckstyleReportGenerator.java:134) > I built version 2.12-SNAPSHOT locally, the NPE still exists. Running with > version 2.10 - no NPE. The code attempts to run Collections.sort on a null > key in the ArrayList from checkstyle results.getFiles().keySet(). This area > of code was not modified in any of the previous revisions going into release > 2.11. The results Collection is populated from > DefaultCheckstyleExecutor.executeChecks calling sinkListener.addDirectory, > but that method code also did not change over the last year. > This bug prevents us from using the latest checkstyle version. If the stack > trace isn't enough to be able to add an extra null value check in > executeChecks, I could run in debug mode and figure where the difference in > values from 2.10 and 2.11 comes from, but it may be a little while before I > can get to that. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-207) file handle leak - leading to failed builds
[ https://jira.codehaus.org/browse/MCHECKSTYLE-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341852#comment-341852 ] Dennis Lundberg commented on MCHECKSTYLE-207: - Hi James, Thanks for the patch. I've had a look at it, and have a question about the logged message in the catch clause. When would that happen? Would it be on Java 7, if and only if the class loader for some reason didn't close correctly? Also, which code is that has a bug in it? The message is a bit confusing to me... > file handle leak - leading to failed builds > --- > > Key: MCHECKSTYLE-207 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-207 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Environment: Linux >Reporter: James Nord > Attachments: MCHECKSTYLE-207_PATCH_V1 (1).txt > > > The plugin sets the classpath to load as a URLClassloader populated with all > the URLs to the projects dependencies (jars) and output folders. > However the URLClassloader is never closed (only available in JDK1.7+) and > for a large multi-module project with a large number of dependencies this > leak can seriously add up (which if gc doesn't kick in at the right moment) > will lead to random failures due to java.io.IOException: error=24, Too many > open files. > see > http://svn.apache.org/viewvc/maven/plugins/tags/maven-checkstyle-plugin-2.11/src/main/java/org/apache/maven/plugin/checkstyle/DefaultCheckstyleExecutor.java?revision=1540890&view=markup > Line 162 where the URLClassloader is created - but never cleaned up. > The fix is relatively trivial if it is only to be fixed for 1.7+ JVMs (and > use reflection if need to be compatable with < 1.7). > Otherwise a custom classloader will be needed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-205) NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression
[ https://jira.codehaus.org/browse/MCHECKSTYLE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHECKSTYLE-205: Affects Version/s: (was: 2.12) > NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression > --- > > Key: MCHECKSTYLE-205 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-205 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11 > Environment: maven-checkstyle-plugin v2.11 and 2.12-SNAPSHOT (as of > 12/5/13). Windows 7, JDK7.45 64 bit, maven 3.1 >Reporter: Bob Fields > Attachments: CheckstyleResults.java.patch > > > This worked in release 2.10, no longer works in 2.11. Running mvn site > against a large project with a parent pom with many subprojects (though no > code in the parent project) (andromda v3.5-SNAPSHOT, from sourceforge). Maven > output: > [INFO] Generating "Checkstyle" report--- > maven-checkstyle-plugin:2.12-SNAPSHOT > [INFO] Starting audit... > ... About 6000 files ... > Audit done. > [INFO] There are 4777 checkstyle errors. > And no additional troubleshooting information, even in debug mode ... > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project > andromda: Execution default-site of goal > org.apache.maven.plugins:maven-site-plugin:3.3:site failed. > NullPointerException -> [Help 1] > Caused by: java.lang.NullPointerException > at java.lang.String.compareTo(String.java:1139) > at java.lang.String.compareTo(String.java:108) > at > java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:290) > at java.util.ComparableTimSort.sort(ComparableTimSort.java:171) > at java.util.ComparableTimSort.sort(ComparableTimSort.java:146) > at java.util.Arrays.sort(Arrays.java:472) > at java.util.Collections.sort(Collections.java:155) > at > org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.doFilesSummary(CheckstyleReportGenerator.java:654) > at > org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.generateReport(CheckstyleReportGenerator.java:134) > I built version 2.12-SNAPSHOT locally, the NPE still exists. Running with > version 2.10 - no NPE. The code attempts to run Collections.sort on a null > key in the ArrayList from checkstyle results.getFiles().keySet(). This area > of code was not modified in any of the previous revisions going into release > 2.11. The results Collection is populated from > DefaultCheckstyleExecutor.executeChecks calling sinkListener.addDirectory, > but that method code also did not change over the last year. > This bug prevents us from using the latest checkstyle version. If the stack > trace isn't enough to be able to add an extra null value check in > executeChecks, I could run in debug mode and figure where the difference in > values from 2.10 and 2.11 comes from, but it may be a little while before I > can get to that. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-196) Broken link to CWiki
[ https://jira.codehaus.org/browse/MCHECKSTYLE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-196. --- Resolution: Fixed Assignee: Benson Margulies This was fixed in r1540563. > Broken link to CWiki > > > Key: MCHECKSTYLE-196 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-196 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.10 > Environment: > http://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html >Reporter: SebbASF >Assignee: Benson Margulies > > http://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html references > the link: > As per href="https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html";>Maven > 3 Compatibility Notes > However the link does not work, as it appears the wiki has been re-organised. > It looks like the correct link is now > https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes > Given that the link may have been referenced from other plugin documentation, > it might be better to add a redirect rather than fix each plugin site > separately. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-198) Add user property for consoleOutput
[ https://jira.codehaus.org/browse/MCHECKSTYLE-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-198. --- Resolution: Duplicate > Add user property for consoleOutput > --- > > Key: MCHECKSTYLE-198 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-198 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.10 >Reporter: Andrew Gaul >Priority: Minor > Attachments: MCHECKSTYLE-198.patch > > > Adding a user property for consoleOutput will allow users to view violations > on arbitrary projects, e.g., > mvn checkstyle:checkstyle -Dcheckstyle.output.console=true -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-190) Add user property for checkstyle:consoleOutput
[ https://jira.codehaus.org/browse/MCHECKSTYLE-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-190. --- Resolution: Fixed Fix Version/s: 2.12 Assignee: Dennis Lundberg Fixed in [r1570751|http://svn.apache.org/viewvc?view=revision&revision=1570751]. > Add user property for checkstyle:consoleOutput > -- > > Key: MCHECKSTYLE-190 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-190 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.9.1 >Reporter: Stephen Cooper >Assignee: Dennis Lundberg > Fix For: 2.12 > > > Some users want checkstyle output on the command line, others don't. > It would be nice if we could specify -Dcheckstyle.consoleOutput=true on the > command line to enable console output as needed/wanted. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-183) Checkstyle fails to compile assignment of anonymous class with generics
[
https://jira.codehaus.org/browse/MCHECKSTYLE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341848#comment-341848
]
Dennis Lundberg commented on MCHECKSTYLE-183:
-
This should be reported to the Checkstyle project at
http://checkstyle.sourceforge.net/
> Checkstyle fails to compile assignment of anonymous class with generics
> ---
>
> Key: MCHECKSTYLE-183
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-183
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
> Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
> Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux", version: "2.6.36-020636-generic", arch: "amd64", family:
> "unix"
>Reporter: Ronald Chen
> Attachments: checkstyles-override-with-generics-fixed.tar.gz
>
>
> Attached is a repo case where checkstyles fails to compile valid code and
> hence fails.
> To run attached code use: mvn checkstyle:check
> The checkstyles parser doesn't like code like:
> {code}
> CheckstylesOverrideWithGenericsBug assigned = new
> CheckstylesOverrideWithGenericsBug() {
> @Overrdie
> public void doStuff(SRC src) {
> }
> };
> {code}
> The workaround is to remove the generics and use a more specific type. In
> the attached file I've include two more other cases which don't reproduce the
> problem.
> Another problem is checkstyles fails when it fails to parse code. This is
> horrible. Checkstyles should skip over files it cannot parse unless you can
> guarantee the checkstyles parser is as good as all other java compilers.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-182) Use Maven log levels when logging to console
[
https://jira.codehaus.org/browse/MCHECKSTYLE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHECKSTYLE-182.
---
Resolution: Fixed
Fix Version/s: 2.12
Assignee: Dennis Lundberg
Patch applied with modifications in
[r1570746|http://svn.apache.org/viewvc?view=revision&revision=1570746]. Many
thanks!
> Use Maven log levels when logging to console
>
>
> Key: MCHECKSTYLE-182
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-182
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Andreas Sewe
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.12
>
> Attachments: patch.diff
>
>
> Getting {{checkstyle:check}} to print out Checkstyle's findings to the
> console during a build is surprisingly hard/ugly:
> {code:xml}
> info
> false
> true
> {code}
> While this achieves the desired effect, it produces a warning:
> {code}
> [WARNING] checkstyle:check violations detected but failOnViolation set to
> false
> {code}
> Moreover, all found violations, whether errors, warnings, or infos, are
> logged as {{[ERROR]}}'s on Maven's console. It would be nice if the
> {{maven-checkstyle-plugin}} would use the corresponding Maven log levels
> instead.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-169) Suppressions property is incorrectly set if suppressions file is on classpath
[ https://jira.codehaus.org/browse/MCHECKSTYLE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-169. --- Resolution: Fixed Fix Version/s: 2.12 Assignee: Dennis Lundberg Patch applied in [r1570730|http://svn.apache.org/viewvc?view=revision&revision=1570730]. Many thanks! > Suppressions property is incorrectly set if suppressions file is on classpath > - > > Key: MCHECKSTYLE-169 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-169 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Sergei Ivanov >Assignee: Dennis Lundberg > Fix For: 2.12 > > Attachments: MCHECKSTYLE-169-bugfix.patch, MCHECKSTYLE-169-it.patch > > > If checkstyle plugin loads suppressions file from its classpath, and the > checkstyle configuration contains suppression filter with a property > placeholder, that property is not expanded because an incorrect path is used. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1066) version 2.14.1 runs tests only if named *Test.java
Max Calderoni created SUREFIRE-1066: --- Summary: version 2.14.1 runs tests only if named *Test.java Key: SUREFIRE-1066 URL: https://jira.codehaus.org/browse/SUREFIRE-1066 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.16, 2.14.1 Reporter: Max Calderoni This is a regression from 2.11, where it was working fine. For TestNG (and JUnit) tests, in order to be run by surefire, all you needed to do is to get the correct annotations in place (@Test) regardless of the name of your test classes. Looks like between version 2.11 and 2.14.1 surefire started *not* running classes whose name did not end with the word 'Test' (like it was few years back, when there were no annotations). That means that upgrading to 2.16 will break previous test code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-212) Upgrade to Checkstyle 5.7
[ https://jira.codehaus.org/browse/MCHECKSTYLE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-212. --- Resolution: Fixed Fix Version/s: 2.12 Assignee: Dennis Lundberg Fixed in [r1570711|http://svn.apache.org/viewvc?view=revision&revision=1570711]. > Upgrade to Checkstyle 5.7 > - > > Key: MCHECKSTYLE-212 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-212 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.11 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.12 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-212) Upgrade to Checkstyle 5.7
Dennis Lundberg created MCHECKSTYLE-212: --- Summary: Upgrade to Checkstyle 5.7 Key: MCHECKSTYLE-212 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-212 Project: Maven Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.11 Reporter: Dennis Lundberg -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341842#comment-341842
]
John Casey edited comment on MRELEASE-812 at 2/21/14 12:19 PM:
---
I've seen this happening in version 2.3.2 also.
I'm just adding this to help others searching for solutions to this. It's a
VERY difficult problem to understand until you sift through the debug console
output...and even then, you have to know what to look for.
If you're using Maven 3.1.1, this behavior will crop up if you don't have a
version specified for the release plugin in your pom.xml, since it seems to be
the default version.
>From an execution using Maven 3.1.1 and release 2.3.2:
{noformat}
[DEBUG] On branch master
[DEBUG] Your branch is up-to-date with 'origin/master'.
[DEBUG]
[DEBUG] Changes to be committed:
[DEBUG] (use "git reset HEAD ..." to unstage)
[DEBUG]
[DEBUG] modified: pom.xml
[DEBUG]
[DEBUG] Untracked files:
[DEBUG] (use "git add ..." to include in what will be committed)
[DEBUG]
[DEBUG] pom.xml.releaseBackup
[DEBUG] prepare.log
[DEBUG] release.properties
[DEBUG]
[INFO] Tagging release with the label buildmetadata-maven-plugin-1.3.1...
{noformat}
was (Author: jdcasey):
I've seen this happening in version 2.3.2 also.
I'm just adding this to help others searching for solutions to this. It's a
VERY difficult problem to understand until you sift through the debug console
output...and even then, you have to know what to look for.
If you're using Maven 3.1.1, this behavior will crop up if you don't have a
version specified for the release plugin in your pom.xml, since it seems to be
the default version.
> "prepare" does not commit before tagging and therefore deploys snapshot
> instead of release
> --
>
> Key: MRELEASE-812
> URL: https://jira.codehaus.org/browse/MRELEASE-812
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.3.2, 2.4
>Reporter: Andrei Pozolotin
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 2.5
>
> Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt
>
>
> thank you very much for new release!
> http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
> it seems we need an emergency fix:
> attached are 2 logs:
> 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
> 2) mvn-2.4.0.txt invocation that fails with 2.4
> problem:
> "perform" does not commit tags, deploys snapshot instead of release
> here is project parent:
> http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
> build is invoked both times with this:
> mvn --define resume=false release:prepare
> mvn --define resume=false release:perform
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikolaj Izdebski updated MNG-5591:
--
Description:
It looks like Maven 3.2.1 introduced a regression. Installing
extension which provides workspace reader triggers MNG-5503.
Maven resolves artifacts from reactor, workspace, repositories (in
that order). In standard Maven distribution there is no workspace,
but Maven provides an extension point which allows extensions to
install workspace reader by providing a component with role
{{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
Installing workspace reader extension in Maven 3.2.1 triggers a
regression - Maven fails to resolve artifacts produced by reactor
build (MNG-5503). Even though artifact is present in reactor Maven
queries workspace about it and if artifact is not found there it
continues with repositories. Expected behaviour is resolving artifact
from reactor.
Steps to reproduce this:
1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
2) download dummy-extension.tar.gz and build it with {{mvn package}}
3) download reproducer for MNG-5503 from:
https://bugzilla.redhat.com/attachment.cgi?id=784786
4) try to build reproducer project, it succeeds
5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
6) try to build reproducer project, it fails
When repeating the same steps for Maven 3.1.1 failure is not reproducible.
was:
It looks like Maven 3.2.1 introduced a regression. Installing
extension which provides workspace reader triggers MNG-5503.
Maven resolves artifacts from reactor, workspace, repositories (in
that order). In standard Maven distribution there is no workspace,
but Maven provides an extension point which allows extensions to
install workspace reader by providing a component with role
{{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
Installing workspace reader extension in Maven 3.2.1 triggers a
regression - Maven fails to resolve artifacts produced by reactor
build (MNG-5503). Even though artifact is present in reactor Maven
queries workspace about it and if artifact is not found there it
continues with repositories. Expected behaviour is resolving artifact
from reactor.
Steps to reproduce this:
1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
2) download dummy-extension.tar.gz and build it with {{mvn package}}
3) download reproducer for MNG-5503 from:
https://bugzilla.redhat.com/attachment.cgi?id=784786
4) try to build reproducer project, it succeeds
5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
4) try to build reproducer project, it fails
When repeating the same steps for Maven 3.1.1 failure is not reproducible.
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
> Attachments: dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-176) upgrade to last 5.1.0
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341843#comment-341843 ] Dennis Lundberg commented on MPMD-176: -- I did some checking: * PMD 5.0.5 can be built using Java 5 * There is no mention of the upgrade to Java 6 in the release notes for 5.1.0 * The building instruction at http://pmd.sourceforge.net/pmd-5.1.0/compiling.html says you need Java 5 or newer to compile PMD 5.1.0 * PMD 5.1.0 cannot be built with Java 5 as it has source/target version set to 1.6 for maven-compiler-plugin * Changing that to 1.5 in the pom.xml causes a build failure It seems that the move to Java 1.6 for PMD was intended, but not documented. So we now face a choice: which version to use? Here's what I suggest: # Change the version of PMD to 5.0.5 (which was what this issue said originally) and the title of this issue accordingly # Go through the issues for Maven PMD Plugin and try to fix as many important ones as possible # Release Maven PMD Plugin 3.1, and announce that it will be the last version that supports Java 5 # Create another issue for upgrading to PMD 5.1.0 and schedule that for Maven PMD Plugin 3.2/4.0 # Fix that issue on trunk > upgrade to last 5.1.0 > - > > Key: MPMD-176 > URL: https://jira.codehaus.org/browse/MPMD-176 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > > need a workaround to a PMD bug. > see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MRELEASE-812: Affects Version/s: 2.3.2 I've seen this happening in version 2.3.2 also. I'm just adding this to help others searching for solutions to this. It's a VERY difficult problem to understand until you sift through the debug console output...and even then, you have to know what to look for. If you're using Maven 3.1.1, this behavior will crop up if you don't have a version specified for the release plugin in your pom.xml, since it seems to be the default version. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2, 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
Mikolaj Izdebski created MNG-5591:
-
Summary: Installing workspace reader triggers MNG-5503
Key: MNG-5591
URL: https://jira.codehaus.org/browse/MNG-5591
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Mikolaj Izdebski
Attachments: dummy-extension.tar.gz
It looks like Maven 3.2.1 introduced a regression. Installing
extension which provides workspace reader triggers MNG-5503.
Maven resolves artifacts from reactor, workspace, repositories (in
that order). In standard Maven distribution there is no workspace,
but Maven provides an extension point which allows extensions to
install workspace reader by providing a component with role
{{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
Installing workspace reader extension in Maven 3.2.1 triggers a
regression - Maven fails to resolve artifacts produced by reactor
build (MNG-5503). Even though artifact is present in reactor Maven
queries workspace about it and if artifact is not found there it
continues with repositories. Expected behaviour is resolving artifact
from reactor.
Steps to reproduce this:
1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
2) download dummy-extension.tar.gz and build it with {{mvn package}}
3) download reproducer for MNG-5503 from:
https://bugzilla.redhat.com/attachment.cgi?id=784786
4) try to build reproducer project, it succeeds
5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
4) try to build reproducer project, it fails
When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-176) upgrade to last 5.1.0
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reopened MPMD-176: -- The 5.1.0 version of PMD is compiled with Java 6. This means that Maven PMD Plugin now requires Java 6. Can we contact the PMD team to investigate the possibility of a Java 5 compiled version, or have PMD switched to Java 6? I would very much prefer to have Maven PMD Plugin stay on Java 5 if possible. > upgrade to last 5.1.0 > - > > Key: MPMD-176 > URL: https://jira.codehaus.org/browse/MPMD-176 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1 > > > need a workaround to a PMD bug. > see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-376) 'Username isn't defined.' when generating SCM report if CVS port number is specified in SCM URL
[
https://jira.codehaus.org/browse/SCM-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341836#comment-341836
]
Matteo Turra commented on SCM-376:
--
I get the same 'Username isn't defined' with | as separator or :
Usually I don't specify username for scm connection because it changes
depending who did the checkout and run mvn commands.
I used ${user.name} property to get the current username from shell (ie:
${user.name}@cvs.mycompany.com)
I don't know why in another project I didn't put this property and it works!
> 'Username isn't defined.' when generating SCM report if CVS port number is
> specified in SCM URL
> ---
>
> Key: SCM-376
> URL: https://jira.codehaus.org/browse/SCM-376
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-cvs, maven-scm-site
>Affects Versions: 1.0
>Reporter: Geert Pante
>Priority: Minor
>
> I have an CVS connection URL defined as follows:
> scm:cvs:pserver:contin...@gnllx002.ebit.be:2401:/data01/cvsroot_bkh:VCG_BKH/uBaseBkh
> When I try mvn site, the stage 'Generating "Source Repository" report.' fails
> as shown below.
> If I remove the :2401, it works OK.
> [INFO] Generating "Source Repository" report.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Username isn't defined.
> [INFO]
>
> [INFO] Trace
> java.lang.IllegalArgumentException: Username isn't defined.
> at
> org.apache.maven.scm.provider.cvslib.repository.CvsScmProviderRepository.getCvsRootForCvsPass(CvsScmProviderRepository.java:105)
> at
> org.apache.maven.scm.provider.cvslib.repository.CvsScmProviderRepository.getCvsRoot(CvsScmProviderRepository.java:73)
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.developerAccessCVS(ScmReport.java:479)
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderDeveloperAccessSection(ScmReport.java:323)
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderBody(ScmReport.java:186)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
> at
> org.apache.maven.report.projectinfo.ScmReport.executeReport(ScmReport.java:87)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1065) Allow includesFile and excludesFile parameters to be set from the commandline
Pascal Schumacher created SUREFIRE-1065: --- Summary: Allow includesFile and excludesFile parameters to be set from the commandline Key: SUREFIRE-1065 URL: https://jira.codehaus.org/browse/SUREFIRE-1065 Project: Maven Surefire Issue Type: Improvement Reporter: Pascal Schumacher Priority: Minor It would be nice to be able to set the includesFile and excludesFile parameters from the command line. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-41) Passphrase revealed when backspacing at prompt
[
https://jira.codehaus.org/browse/MGPG-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MGPG-41.
Resolution: Fixed
Assignee: Stephen Connolly
r1570549
Fixed for JVM 1.6+ using reflection. Bug will still be present on JVM 1.5
fallback code path
> Passphrase revealed when backspacing at prompt
> --
>
> Key: MGPG-41
> URL: https://jira.codehaus.org/browse/MGPG-41
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Mac OS X Mountain Lion
> Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600)
> Maven home: /usr/share/maven
> Java version: 1.6.0_37, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
>Reporter: Tony Trinh
>Assignee: Stephen Connolly
> Fix For: 1.5
>
>
> At the "GPG Passphrase" prompt, if I hit the backspace key during the entry,
> the passphrase is printed in cleartext with one less character. For example:
> {code}GPG Passphrase: **^R
> mysecretpasswor*^R
> mysecretpasswo*^R
> mysecretpassw*^R
> mysecretpass*^R
> mysecretpas*^R
> mysecretpa*^R
> mysecretp*^R
> mysecret*^R
> mysecre*^R
> mysecr*^R
> mysec*^R
> myse*^R
> mys*^R
> my*^R
> m*^R
> *^R
> *{code}
> This can be fixed by replacing the {{MaskingThread}} with Java 6's built-in
> password prompt (as the [code
> comment|http://grepcode.com/file/repository.jboss.org/maven2/org.apache.maven.plugins/maven-gpg-plugin/1.0-alpha-4/org/apache/maven/plugin/gpg/GpgSigner.java#217]
> had suggested to do):
> {code:java}Console console = System.console();
> if ( console != null )
> {
> pass = new String( console.readPassword( "GPG Passphrase: " ) );
> }{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MGPG-48) useAgent=true by default
[ https://jira.codehaus.org/browse/MGPG-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MGPG-48. Resolution: Fixed r1570543 > useAgent=true by default > > > Key: MGPG-48 > URL: https://jira.codehaus.org/browse/MGPG-48 > Project: Maven GPG Plugin > Issue Type: Improvement >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Minor > Fix For: 1.5 > > > Since gpg2 no longer supports the --no-use-agent command line parameter and > most systems use gpg2, the default should be changed in order to prevent the > warning about --no-use-agent being deprecated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-49) Add support for --lock-* command line options
[ https://jira.codehaus.org/browse/MGPG-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MGPG-49. Resolution: Fixed r1570541 > Add support for --lock-* command line options > - > > Key: MGPG-49 > URL: https://jira.codehaus.org/browse/MGPG-49 > Project: Maven GPG Plugin > Issue Type: Improvement >Reporter: Stephen Connolly >Assignee: Stephen Connolly > Fix For: 1.5 > > > Some people have their gpg home on a read only file system and thus need > --lock-never > Also addition of support for extra command line arguments would be generally > useful -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-49) Add support for --lock-* command line options
Stephen Connolly created MGPG-49: Summary: Add support for --lock-* command line options Key: MGPG-49 URL: https://jira.codehaus.org/browse/MGPG-49 Project: Maven GPG Plugin Issue Type: Improvement Reporter: Stephen Connolly Some people have their gpg home on a read only file system and thus need --lock-never Also addition of support for extra command line arguments would be generally useful -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-49) Add support for --lock-* command line options
[ https://jira.codehaus.org/browse/MGPG-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MGPG-49: - Fix Version/s: 1.5 Assignee: Stephen Connolly > Add support for --lock-* command line options > - > > Key: MGPG-49 > URL: https://jira.codehaus.org/browse/MGPG-49 > Project: Maven GPG Plugin > Issue Type: Improvement >Reporter: Stephen Connolly >Assignee: Stephen Connolly > Fix For: 1.5 > > > Some people have their gpg home on a read only file system and thus need > --lock-never > Also addition of support for extra command line arguments would be generally > useful -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-48) useAgent=true by default
[ https://jira.codehaus.org/browse/MGPG-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MGPG-48: - Fix Version/s: 1.5 Assignee: Stephen Connolly > useAgent=true by default > > > Key: MGPG-48 > URL: https://jira.codehaus.org/browse/MGPG-48 > Project: Maven GPG Plugin > Issue Type: Improvement >Reporter: Stephen Connolly >Assignee: Stephen Connolly >Priority: Minor > Fix For: 1.5 > > > Since gpg2 no longer supports the --no-use-agent command line parameter and > most systems use gpg2, the default should be changed in order to prevent the > warning about --no-use-agent being deprecated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-48) useAgent=true by default
Stephen Connolly created MGPG-48: Summary: useAgent=true by default Key: MGPG-48 URL: https://jira.codehaus.org/browse/MGPG-48 Project: Maven GPG Plugin Issue Type: Improvement Reporter: Stephen Connolly Priority: Minor Since gpg2 no longer supports the --no-use-agent command line parameter and most systems use gpg2, the default should be changed in order to prevent the warning about --no-use-agent being deprecated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5472) M3 also-make-dependents completely broken
[
https://jira.codehaus.org/browse/MNG-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341805#comment-341805
]
Stephen Connolly commented on MNG-5472:
---
This is a clear duplicate of MNG-5207
> M3 also-make-dependents completely broken
> -
>
> Key: MNG-5472
> URL: https://jira.codehaus.org/browse/MNG-5472
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line, Reactor and workspace
>Affects Versions: 3.0.5
>Reporter: Jörg Schaible
>
> Command-line option -amd (--also-make-dependents) is completely broken in M3.
> Here a list of processed projects with M3:
> {noformat}
> $ mvn-3.0.5 -amd -pl internal/commons/ldap validate
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Scalaris Commons LDAP Project
> [INFO] eIP UsersMgmt Provider LDAP
> [INFO]
>
> [INFO]
>
>
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Scalaris Commons LDAP Project . SUCCESS [0.152s]
> [INFO] eIP UsersMgmt Provider LDAP ... SUCCESS [0.014s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 13.505s
> [INFO] Finished at: Tue Apr 30 09:03:02 CEST 2013
> [INFO] Final Memory: 223M/638M
> [INFO]
>
> {noformat}
> The same with M221:
> {noformat}
> $ mvn-2.2.1 -amd -pl internal/commons/ldap validate
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Scalaris Commons LDAP Project
> [INFO] eIP UsersMgmt Provider LDAP
> [INFO] eIP SecService EJB
> [INFO] eIP SecService Client Commons
> [INFO] eIP Datastore Connector for Scalaris DMS
> [INFO] eIP Datastore Connector integration tests
> [INFO] eIP EventMonitor OraDMS Provider
> [INFO] eIP OracleText PreIdx Commons
> [INFO] eIP OracleText PreIdx EJB
> [INFO] eIP OracleText PreIdx Client Commons
> [INFO] eIP OracleText PreIdx WebClient
> [INFO] eIP OracleText PreIdx EAR
> [INFO] eIP SecService WebClient
> [INFO] eIP SecService WebService
> [INFO] eIP SecService WebServiceX
> [INFO] eIP SecService EAR
> [INFO] eIP SecService WebService Client
> [INFO] eIP SecService WebServiceX Client
> [INFO] eIP UsersMgmt EAR
> [INFO] essencio Exporter Job Processor Service EJB
> [INFO] essencio Exporter Client Commons
> [INFO] essencio Exporter Server
> [INFO] essencio Exporter OraDMS Provider
> [INFO] essencio File Upload WebService
> [INFO] essencio File Upload WebService Client Application
> [INFO] inCursa WebWorkplace
> [INFO] inCursa Base FileUpload Client Configuration
> [INFO] inCursa Base FileUpload WebService
> [INFO] inCursa Base eIP EventMonitor EAR
> [INFO] inCursa Base eIP Server
> [INFO] inCursa Base Workplace
> [INFO] inCursa Base Application Server Configuration
> [INFO] inCursa Solutions Base Distribution
> [INFO] inCursa Base Project Definition
> [INFO] inCursa Base Exporter Server Application Configuration
> [INFO] inCursa Base Exporter EAR
> [INFO] inCursa Base Project
> [INFO] Document Future doculife inCursa Workplace Client
> [INFO] Document Future doculife inCursa Workplace
> [INFO] Document Future doculife Project Distribution
> [INFO]
>
>
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
>
> [INFO] Scalaris Commons LDAP Project . SUCCESS
> [0.048s]
> [INFO] eIP UsersMgmt Provider LDAP ... SUCCESS
> [0.000s]
> [INFO] eIP SecService EJB SUCCESS
> [0.001s]
> [INFO] eIP SecService Client Commons . SUCCESS
> [0.000s]
> [INFO] eIP Datastore Connector for Scalaris DMS .. SUCCESS
> [0.001s]
> [INFO] eIP Datastore Connector integration tests . SUCCESS
> [0.000s]
> [INFO] eIP EventMonitor OraDMS Provider .. SUCCESS
> [0.001s]
> [INFO] eIP OracleText PreIdx Commons . SUCCESS
> [0.000s]
> [INFO] eIP OracleText PreIdx EJB . SUCCESS
> [0.001s]
> [INFO] eIP OracleText PreIdx Client Commons .. SUCCESS
> [0.000s]
> [INFO] eIP Ora
[jira] (MNG-5472) M3 also-make-dependents completely broken
[
https://jira.codehaus.org/browse/MNG-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MNG-5472.
-
Resolution: Duplicate
> M3 also-make-dependents completely broken
> -
>
> Key: MNG-5472
> URL: https://jira.codehaus.org/browse/MNG-5472
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line, Reactor and workspace
>Affects Versions: 3.0.5
>Reporter: Jörg Schaible
>
> Command-line option -amd (--also-make-dependents) is completely broken in M3.
> Here a list of processed projects with M3:
> {noformat}
> $ mvn-3.0.5 -amd -pl internal/commons/ldap validate
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Scalaris Commons LDAP Project
> [INFO] eIP UsersMgmt Provider LDAP
> [INFO]
>
> [INFO]
>
>
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Scalaris Commons LDAP Project . SUCCESS [0.152s]
> [INFO] eIP UsersMgmt Provider LDAP ... SUCCESS [0.014s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 13.505s
> [INFO] Finished at: Tue Apr 30 09:03:02 CEST 2013
> [INFO] Final Memory: 223M/638M
> [INFO]
>
> {noformat}
> The same with M221:
> {noformat}
> $ mvn-2.2.1 -amd -pl internal/commons/ldap validate
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Scalaris Commons LDAP Project
> [INFO] eIP UsersMgmt Provider LDAP
> [INFO] eIP SecService EJB
> [INFO] eIP SecService Client Commons
> [INFO] eIP Datastore Connector for Scalaris DMS
> [INFO] eIP Datastore Connector integration tests
> [INFO] eIP EventMonitor OraDMS Provider
> [INFO] eIP OracleText PreIdx Commons
> [INFO] eIP OracleText PreIdx EJB
> [INFO] eIP OracleText PreIdx Client Commons
> [INFO] eIP OracleText PreIdx WebClient
> [INFO] eIP OracleText PreIdx EAR
> [INFO] eIP SecService WebClient
> [INFO] eIP SecService WebService
> [INFO] eIP SecService WebServiceX
> [INFO] eIP SecService EAR
> [INFO] eIP SecService WebService Client
> [INFO] eIP SecService WebServiceX Client
> [INFO] eIP UsersMgmt EAR
> [INFO] essencio Exporter Job Processor Service EJB
> [INFO] essencio Exporter Client Commons
> [INFO] essencio Exporter Server
> [INFO] essencio Exporter OraDMS Provider
> [INFO] essencio File Upload WebService
> [INFO] essencio File Upload WebService Client Application
> [INFO] inCursa WebWorkplace
> [INFO] inCursa Base FileUpload Client Configuration
> [INFO] inCursa Base FileUpload WebService
> [INFO] inCursa Base eIP EventMonitor EAR
> [INFO] inCursa Base eIP Server
> [INFO] inCursa Base Workplace
> [INFO] inCursa Base Application Server Configuration
> [INFO] inCursa Solutions Base Distribution
> [INFO] inCursa Base Project Definition
> [INFO] inCursa Base Exporter Server Application Configuration
> [INFO] inCursa Base Exporter EAR
> [INFO] inCursa Base Project
> [INFO] Document Future doculife inCursa Workplace Client
> [INFO] Document Future doculife inCursa Workplace
> [INFO] Document Future doculife Project Distribution
> [INFO]
>
>
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
>
> [INFO] Scalaris Commons LDAP Project . SUCCESS
> [0.048s]
> [INFO] eIP UsersMgmt Provider LDAP ... SUCCESS
> [0.000s]
> [INFO] eIP SecService EJB SUCCESS
> [0.001s]
> [INFO] eIP SecService Client Commons . SUCCESS
> [0.000s]
> [INFO] eIP Datastore Connector for Scalaris DMS .. SUCCESS
> [0.001s]
> [INFO] eIP Datastore Connector integration tests . SUCCESS
> [0.000s]
> [INFO] eIP EventMonitor OraDMS Provider .. SUCCESS
> [0.001s]
> [INFO] eIP OracleText PreIdx Commons . SUCCESS
> [0.000s]
> [INFO] eIP OracleText PreIdx EJB . SUCCESS
> [0.001s]
> [INFO] eIP OracleText PreIdx Client Commons .. SUCCESS
> [0.000s]
> [INFO] eIP OracleText PreIdx WebClient ... SUCCESS
> [0.039s
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341804#comment-341804 ] Jörg Schaible commented on MNG-5207: Hi Stephen, bq. A rule of thumb to avoid this issue is that you should list leaf modules first and put modules with transitive dependencies last... Unfortunately it is no option to sort the modules if you deal with about Maven 400 projects nested multiple levels deep. We have some components there which provides services as EJB and their implementation will use other component's EJB clients. Maintaining the build order manually would be a nightmare. bq. Another solution is just to add the dependency of ejb to app and again the project sorter will sort correctly. This is even wrong, because your app should *not* contain the ejb nor their dependencies (those are implementation details), if those dependencies are not exposed through the EJB's API. Typically we declare the ejb-client dependency with a lot of exclusions. BTW: Thanks for investigation. M221 must have taken the transitive deps into account. IMHO this will also solve MNG-5472 > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: Issues to be reviewed for 4.x > > Attachments: mng5207-it.tgz, mng-5207-minimal.tar.gz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[
https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341803#comment-341803
]
Stephen Connolly commented on MNG-5207:
---
FYI the workaround is to change
{code}
app
delegate
ejb
{code}
to
{code}
delegate
ejb
app
{code}
The project sorter will correctly pull ejb ahead of delegate and respects the
order in the modules unless direct dependencies indicate otherwise.
A rule of thumb to avoid this issue is that you should list leaf modules first
and put modules with transitive dependencies last...
Another solution is just to add the dependency of ejb to app and again the
project sorter will sort correctly.
I am currently investigating whether the project sorter is running prior to
dependency resolution. It may be acceptable to resolve ex-reactor dependencies
as early as the project sorter as if they are unavailable we will fail
anyway... though plugins such as shade could make them available later in the
reactor build... perhaps it is acceptable to just produce a best effort sorting
if ex-reactor dependencies are not available when sorting the projects
> [Regression] Maven 3 fails to calculate proper build order with dependencies
> with classifiers
> -
>
> Key: MNG-5207
> URL: https://jira.codehaus.org/browse/MNG-5207
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Reactor and workspace
>Affects Versions: 3.0.3
>Reporter: Jörg Schaible
>Assignee: Jason van Zyl
>Priority: Critical
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mng5207-it.tgz, mng-5207-minimal.tar.gz, MNG-5207.tgz
>
>
> Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in
> proper order, if a transitive dependency (that is part of the reactor build)
> is overruled in the dependencyManagement section with the current SNAPSHOT
> version. Build order is perfectly calculated with Maven 2.2.1.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-411) Enhance merge-maven-repos to work with SNAPSHOT builds
[
https://jira.codehaus.org/browse/WAGON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341801#comment-341801
]
Dan Tran commented on WAGON-411:
i saw the patch, looks maven 3 metadata api fix the bug, we just need to code
it up at wagon-maven-plugin
> Enhance merge-maven-repos to work with SNAPSHOT builds
> --
>
> Key: WAGON-411
> URL: https://jira.codehaus.org/browse/WAGON-411
> Project: Maven Wagon
> Issue Type: Improvement
>Affects Versions: 1.0-beta-3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 02:44:56-0600)
> Maven home: D:\maven\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: D:\j2sdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Jim McCaskey
>
> According to Dan Tran the merge-maven-repos goal does not work with
> SNAPSHOTS. I could not find an issue open for that so here we go.
> Here is a link to my original e-mail with Dan's response.
> http://mail-archives.apache.org/mod_mbox/maven-users/201303.mbox/%3CCAPCjjnGNu2%3DV0ZZ4_tT8%2B-4O0Uq%3DmnD8spE5LSLLEdYD7agU_A%40mail.gmail.com%3E
> FWIW, it appears to me that there is a problem with the maven-metadata.xml
> files that get merged. Here is an example of a badly merged file.
> {code}
>
>
> myGroup
> MyArtifact
> 10.2.6-SNAPSHOT
>
>
> 20130313.165705
> 1
>
> 20130313165705
>
>
> MyClassifier
> zip
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
> pom
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-411) Enhance merge-maven-repos to work with SNAPSHOT builds
[
https://jira.codehaus.org/browse/WAGON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341800#comment-341800
]
Karl Heinz Marbaise commented on WAGON-411:
---
Hm...that's really sad...Ok...
> Enhance merge-maven-repos to work with SNAPSHOT builds
> --
>
> Key: WAGON-411
> URL: https://jira.codehaus.org/browse/WAGON-411
> Project: Maven Wagon
> Issue Type: Improvement
>Affects Versions: 1.0-beta-3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 02:44:56-0600)
> Maven home: D:\maven\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: D:\j2sdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Jim McCaskey
>
> According to Dan Tran the merge-maven-repos goal does not work with
> SNAPSHOTS. I could not find an issue open for that so here we go.
> Here is a link to my original e-mail with Dan's response.
> http://mail-archives.apache.org/mod_mbox/maven-users/201303.mbox/%3CCAPCjjnGNu2%3DV0ZZ4_tT8%2B-4O0Uq%3DmnD8spE5LSLLEdYD7agU_A%40mail.gmail.com%3E
> FWIW, it appears to me that there is a problem with the maven-metadata.xml
> files that get merged. Here is an example of a badly merged file.
> {code}
>
>
> myGroup
> MyArtifact
> 10.2.6-SNAPSHOT
>
>
> 20130313.165705
> 1
>
> 20130313165705
>
>
> MyClassifier
> zip
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
> pom
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-543) japanese filenames cannot be correctly assembled by maven-assembly-plugin
[ https://jira.codehaus.org/browse/MASSEMBLY-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341797#comment-341797 ] Markus KARG commented on MASSEMBLY-543: --- I tried out plexus-archiver 2.4.4 with -Dfile.encoding=UTF-8, but German umlauts still are screwed in ZIP entry names. > japanese filenames cannot be correctly assembled by maven-assembly-plugin > - > > Key: MASSEMBLY-543 > URL: https://jira.codehaus.org/browse/MASSEMBLY-543 > Project: Maven Assembly Plugin > Issue Type: Bug > Environment: Windows XP SP3 Japanese, Eclipse Ganymede 3.4.2 >Reporter: Eros Sy > Attachments: 新規テキスト > ドキュメント.xml > > > I am successfully created the distribution zip file but when I add a file > which is in Japanese character file name, it is include in the zip file but > the file name was garbled. > How to reproduce: add a file to be included in the distribution which file > name is in Japanese character. i will provide a sample file. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341795#comment-341795
]
Tibor Digana commented on MNG-2205:
---
@Jason
The problem is that the behavior has changed after Maven 2.2.1.
New keywords would not be acceptable by the community in my guess - this may
take quite long time to implement and finally the Maven users may get lost.
I prefer simplicity and correct behavior against huge number of keywords.
The right solution would be to concentrate on fixing hunderds of bugs in the
Maven project. First of all to write tests against Maven 2 behavior and then
run the same tests on Maven 3, let's see what will happen.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-411) Enhance merge-maven-repos to work with SNAPSHOT builds
[
https://jira.codehaus.org/browse/WAGON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341792#comment-341792
]
Dan Tran commented on WAGON-411:
this has nothing to do with wagon itself, it should be back and MOJO and the
fix is actually maven core or maven metadata not supporting snapshot merging
> Enhance merge-maven-repos to work with SNAPSHOT builds
> --
>
> Key: WAGON-411
> URL: https://jira.codehaus.org/browse/WAGON-411
> Project: Maven Wagon
> Issue Type: Improvement
>Affects Versions: 1.0-beta-3
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 02:44:56-0600)
> Maven home: D:\maven\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: D:\j2sdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Jim McCaskey
>
> According to Dan Tran the merge-maven-repos goal does not work with
> SNAPSHOTS. I could not find an issue open for that so here we go.
> Here is a link to my original e-mail with Dan's response.
> http://mail-archives.apache.org/mod_mbox/maven-users/201303.mbox/%3CCAPCjjnGNu2%3DV0ZZ4_tT8%2B-4O0Uq%3DmnD8spE5LSLLEdYD7agU_A%40mail.gmail.com%3E
> FWIW, it appears to me that there is a problem with the maven-metadata.xml
> files that get merged. Here is an example of a badly merged file.
> {code}
>
>
> myGroup
> MyArtifact
> 10.2.6-SNAPSHOT
>
>
> 20130313.165705
> 1
>
> 20130313165705
>
>
> MyClassifier
> zip
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
> pom
> 10.2.6-20130311.175410-1
> 20130311175410
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1063) Typo in error message
[
https://jira.codehaus.org/browse/SUREFIRE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1063:
-
Fix Version/s: 2.17
> Typo in error message
> -
>
> Key: SUREFIRE-1063
> URL: https://jira.codehaus.org/browse/SUREFIRE-1063
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15
>Reporter: Gili
>Priority: Minor
> Fix For: 2.17
>
>
> When Surefire fails, it dies with the following message:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-cli) on
> project web.backend: Execution default-cli of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> [ERROR] Command wascmd.exe /X /C [etc]
> {code}
> Please fix the error message so "wascmd.exe" is "was cmd.exe". This used to
> be correct, but someone broke it a few releases back.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1063) Typo in error message
[
https://jira.codehaus.org/browse/SUREFIRE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341791#comment-341791
]
Andreas Gudian commented on SUREFIRE-1063:
--
There's a pull-request on github already for this (and lots of other typos):
https://github.com/apache/maven-surefire/pull/32
We'll merge it in time for 2.17.
> Typo in error message
> -
>
> Key: SUREFIRE-1063
> URL: https://jira.codehaus.org/browse/SUREFIRE-1063
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.15
>Reporter: Gili
>Priority: Minor
>
> When Surefire fails, it dies with the following message:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-cli) on
> project web.backend: Execution default-cli of goal
> org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked
> VM terminated without saying properly goodbye. VM crash or System.exit called
> ?
> [ERROR] Command wascmd.exe /X /C [etc]
> {code}
> Please fix the error message so "wascmd.exe" is "was cmd.exe". This used to
> be correct, but someone broke it a few releases back.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
