[jira] Commented: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250917#action_250917
]
Barrie Treloar commented on MRELEASE-128:
-
Anthony, it's open source. Feel free to roll up the sleeves and provide some
help to get it resolved.
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 2.2
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250913#action_250913
]
Anthony Whitford commented on MRELEASE-128:
---
*Has this issue really been open for more than _4 years_?*
This is a critical one for me; I am unable to adopt the latest release plugin
until this is resolved.
I think this also impairs my progress towards Maven 3.
*I'd really appreciate this being resolved!* Thanks!
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
>Reporter: Craig Dickson
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 2.2
>
> Attachments: after-release-perform-pom.xml,
> after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
> MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250907#action_250907 ] Andrei Pozolotin commented on MNG-4965: --- done: https://issues.sonatype.org/browse/NEXUS-4055 > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250906#action_250906 ] Benjamin Bentmann commented on MNG-4965: If usage of Nexus introduces the trouble, then please report the issue at https://issues.sonatype.org/browse/NEXUS. > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250904#action_250904 ] Andrei Pozolotin commented on MNG-4965: --- actually, I was able to reproduce the issue with 3.0.1: 1) if I run mvn against "real" snapshot repo - all works; 2) but if I run mvn against a nexus which is a proxy to the "real" repo - then the problems are as I described; > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250905#action_250905 ] Andrei Pozolotin commented on MNG-4965: --- proxy nexus info: Sonatype Nexus Open Source Edition, Version: 1.8.0.1 > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4912) Use of raw type should be Comparable
[
http://jira.codehaus.org/browse/MNG-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4912:
---
Issue Type: Improvement (was: Bug)
> Use of raw type should be Comparable
> -
>
> Key: MNG-4912
> URL: http://jira.codehaus.org/browse/MNG-4912
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.0
>Reporter: Jesse Glick
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0.2
>
> Attachments: ArtifactVersion-Comparable.diff
>
>
> To avoid raw type and unchecked warnings, {{ArtifactVersion}} should
> implement {{Comparable}}, not raw {{Comparable}}. Compare
> {{interface Artifact extends Comparable}} etc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
[ http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250896#action_250896 ] Andrei Pozolotin commented on MNG-4965: --- Benjamin: thanks for looking into this; yes, you are right! (although I was sure I triple checked everything before filing a bug) thanks again! Andrei > resolver fails to find artifacts with classifiers from previous deployments > --- > > Key: MNG-4965 > URL: http://jira.codehaus.org/browse/MNG-4965 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.1 > Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64, > windows x86, windows x86_64 > jdk 1.6.0_23 x32, jdk 1.6.0_23 x64 > maven 3.0.1 >Reporter: Andrei Pozolotin >Assignee: Benjamin Bentmann > > please see my comment and detailed example to the issue > MNG-4452 > http://jira.codehaus.org/browse/MNG-4452 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-645) Meaningful message when test has no runnable methods
[ http://jira.codehaus.org/browse/SUREFIRE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Birkner updated SUREFIRE-645: Attachment: surefire645WithJunit3Fix.patch > Meaningful message when test has no runnable methods > > > Key: SUREFIRE-645 > URL: http://jira.codehaus.org/browse/SUREFIRE-645 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: Backlog >Reporter: Stefan Birkner > Fix For: 2.7.2 > > Attachments: extendedErrorMessage.patch, surefire645_revised.patch, > surefire645WithJunit3Fix.patch > > > If there's a test class without any runnable methods, the test fails with an > error. The output to the command line is: > Tests in error: > initializationError(EmptyTest) > The supplied patch extends this message for all errors. For the error at > hand, the output to the command line will be: > Tests in error: > initializationError(EmptyTest): No runnable methods -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-645) Meaningful message when test has no runnable methods
[ http://jira.codehaus.org/browse/SUREFIRE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250895#action_250895 ] Stefan Birkner commented on SUREFIRE-645: - The bug still exists for JUnit3 tests. If there's a JUnit 3 test class without any runnable methods, the test fails. The output to the command line is: Failed tests: warning(junit.framework.TestSuite$1) The supplied patch extends this message for all failures. For the failure at hand, the output to the command line will be: Failed tests: warning(junit.framework.TestSuite$1): No tests found in junit.norunnabletests.BasicTest I create a new patch, that fixes this bug. > Meaningful message when test has no runnable methods > > > Key: SUREFIRE-645 > URL: http://jira.codehaus.org/browse/SUREFIRE-645 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: Backlog >Reporter: Stefan Birkner > Fix For: 2.7.2 > > Attachments: extendedErrorMessage.patch, surefire645_revised.patch > > > If there's a test class without any runnable methods, the test fails with an > error. The output to the command line is: > Tests in error: > initializationError(EmptyTest) > The supplied patch extends this message for all errors. For the error at > hand, the output to the command line will be: > Tests in error: > initializationError(EmptyTest): No runnable methods -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-540) Site plugin cannot parse checkstyle configuration when inherited
Site plugin cannot parse checkstyle configuration when inherited Key: MSITE-540 URL: http://jira.codehaus.org/browse/MSITE-540 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: inheritance, multi module, site:run Affects Versions: 3.0-beta-3 Environment: Maven 3.0.1, Windows XP SP2 Reporter: Martin Ackermann Priority: Minor Attachments: example-project.zip When running "mvn site" on the atteched example project, the following error occurs: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on project parent: failed to get Reports: Unable to parse configuration of mojo org.apache.maven.plugins:maven-jxr-plugin:2.2:jxr for parameter excludes: Cannot assign configuration entry 'excludes' to 'class java.util.ArrayList' from 'mypackage/**/*.java', which is of type class java.lang.String -> [Help 1] Obviously, the parser gets out of scope because it complains about 'excludes' for the jxr plugin. But the 'excludes' is actually given in the checkstyle plugin section. If you delete the jxr plugin section from pluginManagement, the error disappears. If you delete the javadoc plugin section from plugins, the error disappears as well. If you change the order of the checkstyle plugin section and the jxr plugin section under pluginManagement, the error disappears as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4960) [regression] Make-like reactor mode does not build selected project when resuming from one of its prerequisites
[
http://jira.codehaus.org/browse/MNG-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4960.
--
Resolution: Fixed
Fix Version/s: 3.0.2
Assignee: Benjamin Bentmann
Fixed in [r1056770|http://svn.apache.org/viewvc?view=revision&revision=1056770].
> [regression] Make-like reactor mode does not build selected project when
> resuming from one of its prerequisites
> ---
>
> Key: MNG-4960
> URL: http://jira.codehaus.org/browse/MNG-4960
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0, 3.0.1
> Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 02:58:32-0800)
> Java version: 1.6.0_19
> OS name: Windows XP/Vista
>Reporter: Sujit Kabbinahally
>Assignee: Benjamin Bentmann
> Fix For: 3.0.2
>
> Attachments: Maven3 Command Line.zip, Maven3 Command Line.zip,
> MNG-4960.zip, MNG-4960_SK.zip
>
>
> As of now in Maven2 (2.2.1) we are able to build a multi-module enterprise
> project as explained below and the same does not work in Maven3 (3.0.1) after
> the migration.
> Basically in the multi-module enterprise project, we build multiple ear's
> with their own dependents and each one of these EAR's is built as its own
> module by inheriting properties/attributes etc from the parent pom at the
> base level of the whole project.
> In Maven2, the below command to accomplish the above explanation works as
> expected when initiated from the ${project.basedir} of the main project.
> mvn -pl ear_module -am -rf first_dependent_module clean install -P
> @ build time, the reactor lists the build order as shown below
>1. first_dependent_module
>2. second_dependent_module
>3. ear_module
> Option '-rf' is used to NOT delete the target folder at the main
> ${project.basedir} since we want to still keep the output from the build of
> another EAR and its dependents.
> With Maven3, however, the reactor lists the build order as shown below:
>1. first_dependent_module
>2. second_dependent_module
> Maven3 ignores the argument (ear_module) set to '-pl' option to be also built
> after its dependents have been.
>
> This behavior can be made to work only if '-rf' option is removed from the
> command and i.e. call 'mvn -pl ear_module -am clean install -P '
> which defeats the whole purpose of NOT deleting the 'target' folder under
> under base ${project.basedir}.
> Attached doc has screen shots to display the behavior explained above for all
> cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4960) [regression] Make-like reactor mode does not build selected project when resuming from one of its prerequisites
[
http://jira.codehaus.org/browse/MNG-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4960:
---
Summary: [regression] Make-like reactor mode does not build selected
project when resuming from one of its prerequisites (was: Maven3 behaves
differently than Maven2 when building a multi-module enterprise project on
command line)
> [regression] Make-like reactor mode does not build selected project when
> resuming from one of its prerequisites
> ---
>
> Key: MNG-4960
> URL: http://jira.codehaus.org/browse/MNG-4960
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0, 3.0.1
> Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 02:58:32-0800)
> Java version: 1.6.0_19
> OS name: Windows XP/Vista
>Reporter: Sujit Kabbinahally
> Attachments: Maven3 Command Line.zip, Maven3 Command Line.zip,
> MNG-4960.zip, MNG-4960_SK.zip
>
>
> As of now in Maven2 (2.2.1) we are able to build a multi-module enterprise
> project as explained below and the same does not work in Maven3 (3.0.1) after
> the migration.
> Basically in the multi-module enterprise project, we build multiple ear's
> with their own dependents and each one of these EAR's is built as its own
> module by inheriting properties/attributes etc from the parent pom at the
> base level of the whole project.
> In Maven2, the below command to accomplish the above explanation works as
> expected when initiated from the ${project.basedir} of the main project.
> mvn -pl ear_module -am -rf first_dependent_module clean install -P
> @ build time, the reactor lists the build order as shown below
>1. first_dependent_module
>2. second_dependent_module
>3. ear_module
> Option '-rf' is used to NOT delete the target folder at the main
> ${project.basedir} since we want to still keep the output from the build of
> another EAR and its dependents.
> With Maven3, however, the reactor lists the build order as shown below:
>1. first_dependent_module
>2. second_dependent_module
> Maven3 ignores the argument (ear_module) set to '-pl' option to be also built
> after its dependents have been.
>
> This behavior can be made to work only if '-rf' option is removed from the
> command and i.e. call 'mvn -pl ear_module -am clean install -P '
> which defeats the whole purpose of NOT deleting the 'target' folder under
> under base ${project.basedir}.
> Attached doc has screen shots to display the behavior explained above for all
> cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-645) Meaningful message when test has no runnable methods
[
http://jira.codehaus.org/browse/SUREFIRE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250884#action_250884
]
Stefan Birkner commented on SUREFIRE-645:
-
The test case must be a JUnit4 test:
public class BasicTest
{
}
The bug can be reproduced with version 2.6 of Surefire. The bug has been fixed
in Version 2.7, which doesn't try to run the test.
> Meaningful message when test has no runnable methods
>
>
> Key: SUREFIRE-645
> URL: http://jira.codehaus.org/browse/SUREFIRE-645
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: Backlog
>Reporter: Stefan Birkner
> Fix For: 2.7.2
>
> Attachments: extendedErrorMessage.patch, surefire645_revised.patch
>
>
> If there's a test class without any runnable methods, the test fails with an
> error. The output to the command line is:
> Tests in error:
> initializationError(EmptyTest)
> The supplied patch extends this message for all errors. For the error at
> hand, the output to the command line will be:
> Tests in error:
> initializationError(EmptyTest): No runnable methods
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCHECKSTYLE-134) suppressionsFileExpression does not work - cannot initialize module SuppressionFilter
[
http://jira.codehaus.org/browse/MCHECKSTYLE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250875#action_250875
]
Savas Ali Tokmen edited comment on MCHECKSTYLE-134 at 1/8/11 9:56 AM:
--
Thank you for the workaround.
BTW, why isn't the patch applied yet?
was (Author: alitokmen):
Thank you for the workaround
> suppressionsFileExpression does not work - cannot initialize module
> SuppressionFilter
> -
>
> Key: MCHECKSTYLE-134
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-134
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Felix Röthenbacher
> Attachments: MCHECKSTYLE-134.diff.txt
>
>
> Setting the checkstyle.suppressions.file property through
> suppressionsFileExpression doesn't work:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file
>
> Output:
> [INFO] Failed during checkstyle configuration
>
>
> Embedded error: cannot initialize module SuppressionFilter - Cannot set
> property 'file' in module SuppressionFilter to
> 'checkstyle.suppressions.file': unable to find checkstyle.suppressions.file
> checkstyle.suppressions.file (No such file or directory)
> -
> Workaround:
> Using a different property name for suppressionsFileExpression and setting
> property manually works though:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file.donothing
>
> checkstyle.suppressions.file=${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-134) suppressionsFileExpression does not work - cannot initialize module SuppressionFilter
[
http://jira.codehaus.org/browse/MCHECKSTYLE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250875#action_250875
]
Savas Ali Tokmen commented on MCHECKSTYLE-134:
--
Thank you for the workaround
> suppressionsFileExpression does not work - cannot initialize module
> SuppressionFilter
> -
>
> Key: MCHECKSTYLE-134
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-134
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Felix Röthenbacher
> Attachments: MCHECKSTYLE-134.diff.txt
>
>
> Setting the checkstyle.suppressions.file property through
> suppressionsFileExpression doesn't work:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file
>
> Output:
> [INFO] Failed during checkstyle configuration
>
>
> Embedded error: cannot initialize module SuppressionFilter - Cannot set
> property 'file' in module SuppressionFilter to
> 'checkstyle.suppressions.file': unable to find checkstyle.suppressions.file
> checkstyle.suppressions.file (No such file or directory)
> -
> Workaround:
> Using a different property name for suppressionsFileExpression and setting
> property manually works though:
>
>
> ${project.build.directory}/checkstyle/checkstyle.xml
>
> ${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
> checkstyle.suppressions.file.donothing
>
> checkstyle.suppressions.file=${project.build.directory}/checkstyle/checkstyle-suppressions.xml
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-581) URL mangling should preserve double slashes
[
http://jira.codehaus.org/browse/SCM-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed SCM-581.
-
Resolution: Duplicate
Assignee: Benjamin Bentmann
> URL mangling should preserve double slashes
> ---
>
> Key: SCM-581
> URL: http://jira.codehaus.org/browse/SCM-581
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Affects Versions: 1.4
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
>Reporter: Andreas Sewe
>Assignee: Benjamin Bentmann
>
> AFAIK, Mercurial allows for URLs like
> {{ssh://example.org//home/sewe/example-project/}}. Unfortunately, the
> Mercurial SCM provider turns this into {{hg push
> ssh://example.org/home/sewe/example-project/}}, which fails if, e.g., the
> Mercurial server is configured to look for repositories in the user's home
> directory (may or may not be {{/home/sewe}}, depending on your login)
> *unless* an absolute path is explicitly requested by using a path starting
> with a double slash.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4966) Preserve double slashes in the scm connection url - identifies absolute repository paths for mercurial
[ http://jira.codehaus.org/browse/MNG-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4966. -- Resolution: Fixed Fix Version/s: 3.0.2 Assignee: Benjamin Bentmann Fixed in [r1056720|http://svn.apache.org/viewvc?view=revision&revision=1056720]. > Preserve double slashes in the scm connection url - identifies absolute > repository paths for mercurial > -- > > Key: MNG-4966 > URL: http://jira.codehaus.org/browse/MNG-4966 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0, 3.0.1 >Reporter: Fredrik Jonson >Assignee: Benjamin Bentmann > Fix For: 3.0.2 > > Attachments: maven-3.0-preserve-double-shashes.patch > > > The mercurial scm (hg) use double slashes after the hostname part of the > repository url to identify that a repository path is absolute, as opposed to > relative. Maven should not remove such double slashes from the scm connection > url. > The following is an example of a absolute repository path: > scm:hg:ssh://localhost//opt/foo. Note the double slash between 'localhost' > and 'opt', it is interpreted by hg as the absolute path /opt/foo on the > server localhost. > A relative repository url on the other hand, scm:hg:ssh://localhost/foo, is > resolved relative to the user's home directory on the server localhost, f.x > /home/user/foo. > With maven 3.0 and 3.0.1 double slashes are silently removed and it is thus > not possible to release a project that use a absolute scm connection url with > mercurial. > The provide patch removes the removal of double slashes from the url > normalizer. It also change the test case for the removal code to test that > url:s that contain double slashes are preserved instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4965) resolver fails to find artifacts with classifiers from previous deployments
[
http://jira.codehaus.org/browse/MNG-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4965.
--
Resolution: Incomplete
Assignee: Benjamin Bentmann
{quote}
[INFO] Building Unnamed -
com.barchart.udt:barchart-udt4-bundle:jar:1.0.0-SNAPSHOT
[INFO] task-segment: [validate]
{quote}
This log pretty clearly proves that you are not running Maven 3.0 or 3.0.1.
> resolver fails to find artifacts with classifiers from previous deployments
> ---
>
> Key: MNG-4965
> URL: http://jira.codehaus.org/browse/MNG-4965
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.1
> Environment: ubntu i386, ubuntu amd64, macosx i386, macos x86_64,
> windows x86, windows x86_64
> jdk 1.6.0_23 x32, jdk 1.6.0_23 x64
> maven 3.0.1
>Reporter: Andrei Pozolotin
>Assignee: Benjamin Bentmann
>
> please see my comment and detailed example to the issue
> MNG-4452
> http://jira.codehaus.org/browse/MNG-4452
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4966) Preserve double slashes in the scm connection url - identifies absolute repository paths for mercurial
Preserve double slashes in the scm connection url - identifies absolute repository paths for mercurial -- Key: MNG-4966 URL: http://jira.codehaus.org/browse/MNG-4966 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.1, 3.0 Reporter: Fredrik Jonson Attachments: maven-3.0-preserve-double-shashes.patch The mercurial scm (hg) use double slashes after the hostname part of the repository url to identify that a repository path is absolute, as opposed to relative. Maven should not remove such double slashes from the scm connection url. The following is an example of a absolute repository path: scm:hg:ssh://localhost//opt/foo. Note the double slash between 'localhost' and 'opt', it is interpreted by hg as the absolute path /opt/foo on the server localhost. A relative repository url on the other hand, scm:hg:ssh://localhost/foo, is resolved relative to the user's home directory on the server localhost, f.x /home/user/foo. With maven 3.0 and 3.0.1 double slashes are silently removed and it is thus not possible to release a project that use a absolute scm connection url with mercurial. The provide patch removes the removal of double slashes from the url normalizer. It also change the test case for the removal code to test that url:s that contain double slashes are preserved instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-666) Aggregate report is empty for multimodule build.
[
http://jira.codehaus.org/browse/SUREFIRE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250865#action_250865
]
Martin Ackermann commented on SUREFIRE-666:
---
I'm struggling with the same problem. I'm using Maven 3.0.1, Surefire 2.7.1 and
Site 3.0-beta-3 and "mvn site-deploy", but the problem is the same. The problem
seems to be that the aggregate surefire report for the parent is generated
before the surefire plugin runs the tests for the child modules. So the
aggregate surefire report doesn't find any surefire test results for the child
modules. The indication is in the log: "[INFO] Generating 'Surefire Report'
report" for the parent occurs before "[INFO] Building ".
If I run "mvn clean mvn site-deploy; mvn site-deploy", the resulting aggregate
surefire report is correct. The reason might be that the second site-deploy run
collects the surefire results for the child modules from the previous run. "mvn
clean test; mvn site-deploy" works as well. These workarounds only work under
the condition, that "" is not set to "false" for the surefire report
plugin in the reporting section of the parent pom.
(In contrast, "mvn clean site-deploy site-deploy" and "mvn clean test
site-deploy" behave different and don't provide the correct surefire results
when working on previously cleaned target directories.)
Marcin, did you try "mvn clean mvn site:stage -Daggregate=true; mvn site:stage
-Daggregate=true" as workaround?
My question to the experts: Why does the surefire report plugin not immediately
descend to the child modules, compile and test them while executing the
aggregate report for the parent module?
Kind regards, Martin.
BTW: Marcin, you set "Affects Version/s" to 2.6, but in your corporate pom.xml,
you specify 2.7. Maybe the pom.xml in your svn repository has evolved
meanwhile...
> Aggregate report is empty for multimodule build.
>
>
> Key: SUREFIRE-666
> URL: http://jira.codehaus.org/browse/SUREFIRE-666
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.6
> Environment: Maven 2.2.1
>Reporter: Marcin Kuthan
> Attachments: core.png, parent.png
>
>
> When the report aggregation is enabled:
> 1. On module level empty surefire report page is generated
> 2. On top level surefire report with 0 tests is generated
> Surefire report plugin configuration:
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> ${plugins.surefireVersion}
>
>
> ${project.build.directory}/surefire-reports/
> ${project.build.directory}/failsafe-reports/
>
>
>
>
>
> report-only
>
>
>
>
> To reproduce the issue:
> 1. svn checkout http://m4enterprise.googlecode.com/svn/trunk/
> m4enterprise-read-only
> 2. call "mvn install" against corporate-pom and modular-war modules.
> 3. call "mvn site:stage -Daggregate=true" against modular-war.
> 4. check the reports in modular-war/target/stage directory.
> I was looking for description how to configure surefire and failsafe together
> for multi module project. No luck :-(
> Thanks,
> Marcin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
