[jira] Updated: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Whelan updated MCHECKSTYLE-163:
-
Attachment: MCHECKSTYLE-163.zip
Attaching an example project
Test classpath resolution fails in mvn check:check when
includeTestSourceDirectory = true
-
Key: MCHECKSTYLE-163
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Chris Whelan
Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
full test classpath should be made available to checkstyle. Patch included
to resolve issue by setting @requiresDependencyResolution to test.
In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
using the classpath string from
request.getProject().getTestClasspathElements() (see
DefaultCheckstyleExecutor line 114).
However, the CheckstyleViolationCheckMojo only has
@requiresDependencyResolution compile which means that pom dependencies which
have been declared as scopetest/scope are not returned by
project.getTestClasspathElements().
This is a particular issue for the checkstyle RedundantThrows check
(http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
requires all Exceptions to be available on it's classpath.
If code throws an Exception which has been imported from a maven
scopetest/scope dependency, the exception will not be available on the
classpath and this checkstyle check will fail.
Example:
Include junit as a test scope dependency in the project POM:
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${junit.version}/version
scopetest/scope
/dependency
Throw any junit exception within project test code, e.g.:
public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
public MyCustomTestRunner(final Class? klass) throws
InitializationError {
If RedundantThrows check is enabled, the following error will be thrown:
[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
sample-project ---
[INFO] Starting audit...
C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
warning: Unable to get class information for InitializationError.
Audit done.
[ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
InitializationError.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[ https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274866#comment-274866 ] Chris Whelan commented on MCHECKSTYLE-163: -- Example log running attached project without patch. Note the 'unable to get class information' errors: C:\Working\MCHECKSTYLE-163mvn clean verify [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for sample:sample:pom:1.0-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 47, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] [INFO] Building Example project 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ sample --- [INFO] Deleting C:\Working\MCHECKSTYLE-163\target [INFO] [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @ sample --- [WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent! [INFO] Starting audit... C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:7:59: warning: Unable to get class information for InitializationError. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:9:62: warning: Unable to get class information for InitializationError. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:13:74: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. Audit done. [ERROR] Example.java[7:59] Unable to get class information for InitializationError. [ERROR] Example.java[9:62] Unable to get class information for InitializationError. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is unchecked exception. [ERROR] Example.java[13:74] Redundant throws: 'IllegalArgumentException' is unchecked exception. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.406s [INFO] Finished at: Wed Aug 03 13:57:37 SGT 2011 [INFO] Final Memory: 4M/15M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) on project sample: You have 5 Checkstyle violations. - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true - Key: MCHECKSTYLE-163 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.7 Reporter: Chris Whelan Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the full test classpath should be made available to checkstyle. Patch included to resolve issue by setting @requiresDependencyResolution to test. In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured using the classpath string from request.getProject().getTestClasspathElements() (see DefaultCheckstyleExecutor line 114). However, the CheckstyleViolationCheckMojo only has @requiresDependencyResolution compile which means that pom dependencies which have been declared as scopetest/scope are not returned by project.getTestClasspathElements(). This is a particular issue for the checkstyle RedundantThrows check (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it requires all Exceptions to be available on it's classpath. If code
[jira] Commented: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[ https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274868#comment-274868 ] Chris Whelan commented on MCHECKSTYLE-163: -- Example log with patch applied. Note that build now fails for the correct reason and all four Redundant throws errors are shown in the console. C:\Working\MCHECKSTYLE-163mvn clean verify [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for sample:sample:pom:1.0-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 47, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] [INFO] Building Example project 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ sample --- [INFO] Deleting C:\Working\MCHECKSTYLE-163\target [INFO] [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @ sample --- [WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent! [INFO] Starting audit... C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:7:59: warning: Redundant throws: 'InitializationError' is subclass of 'Exception'. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:13:74: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. Audit done. [ERROR] Example.java[7:59] Redundant throws: 'InitializationError' is subclass of 'Exception'. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is unchecked exception. [ERROR] Example.java[13:74] Redundant throws: 'IllegalArgumentException' is unchecked exception. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.500s [INFO] Finished at: Wed Aug 03 13:58:55 SGT 2011 [INFO] Final Memory: 4M/15M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) on project sample: You have 4 Checkstyle violations. - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true - Key: MCHECKSTYLE-163 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.7 Reporter: Chris Whelan Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the full test classpath should be made available to checkstyle. Patch included to resolve issue by setting @requiresDependencyResolution to test. In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured using the classpath string from request.getProject().getTestClasspathElements() (see DefaultCheckstyleExecutor line 114). However, the CheckstyleViolationCheckMojo only has @requiresDependencyResolution compile which means that pom dependencies which have been declared as scopetest/scope are not returned by project.getTestClasspathElements(). This is a particular issue for the checkstyle RedundantThrows check (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it requires all Exceptions to be available on it's classpath. If code throws an Exception which has been imported from a maven scopetest/scope dependency, the exception will not be available on the classpath and this
[jira] Updated: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MCHECKSTYLE-163:
-
Affects Version/s: (was: 2.7)
2.6
Fix Version/s: 2.7
Assignee: Olivier Lamy
Test classpath resolution fails in mvn check:check when
includeTestSourceDirectory = true
-
Key: MCHECKSTYLE-163
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Chris Whelan
Assignee: Olivier Lamy
Fix For: 2.7
Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
full test classpath should be made available to checkstyle. Patch included
to resolve issue by setting @requiresDependencyResolution to test.
In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
using the classpath string from
request.getProject().getTestClasspathElements() (see
DefaultCheckstyleExecutor line 114).
However, the CheckstyleViolationCheckMojo only has
@requiresDependencyResolution compile which means that pom dependencies which
have been declared as scopetest/scope are not returned by
project.getTestClasspathElements().
This is a particular issue for the checkstyle RedundantThrows check
(http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
requires all Exceptions to be available on it's classpath.
If code throws an Exception which has been imported from a maven
scopetest/scope dependency, the exception will not be available on the
classpath and this checkstyle check will fail.
Example:
Include junit as a test scope dependency in the project POM:
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${junit.version}/version
scopetest/scope
/dependency
Throw any junit exception within project test code, e.g.:
public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
public MyCustomTestRunner(final Class? klass) throws
InitializationError {
If RedundantThrows check is enabled, the following error will be thrown:
[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
sample-project ---
[INFO] Starting audit...
C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
warning: Unable to get class information for InitializationError.
Audit done.
[ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
InitializationError.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCHECKSTYLE-163.
Resolution: Fixed
fixed in [rev
1153384|http://svn.apache.org/viewvc?view=revisionsortby=logrevision=1153384]
Thanks !
Test classpath resolution fails in mvn check:check when
includeTestSourceDirectory = true
-
Key: MCHECKSTYLE-163
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.6
Reporter: Chris Whelan
Assignee: Olivier Lamy
Fix For: 2.7
Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
full test classpath should be made available to checkstyle. Patch included
to resolve issue by setting @requiresDependencyResolution to test.
In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
using the classpath string from
request.getProject().getTestClasspathElements() (see
DefaultCheckstyleExecutor line 114).
However, the CheckstyleViolationCheckMojo only has
@requiresDependencyResolution compile which means that pom dependencies which
have been declared as scopetest/scope are not returned by
project.getTestClasspathElements().
This is a particular issue for the checkstyle RedundantThrows check
(http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
requires all Exceptions to be available on it's classpath.
If code throws an Exception which has been imported from a maven
scopetest/scope dependency, the exception will not be available on the
classpath and this checkstyle check will fail.
Example:
Include junit as a test scope dependency in the project POM:
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${junit.version}/version
scopetest/scope
/dependency
Throw any junit exception within project test code, e.g.:
public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
public MyCustomTestRunner(final Class? klass) throws
InitializationError {
If RedundantThrows check is enabled, the following error will be thrown:
[INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
sample-project ---
[INFO] Starting audit...
C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
warning: Unable to get class information for InitializationError.
Audit done.
[ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
InitializationError.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-87) Compiler errors display as INFO level messages
[ https://jira.codehaus.org/browse/MCOMPILER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274894#comment-274894 ] Robin Vobruba commented on MCOMPILER-87: indeed :/ sorry! i tested, and it was fixed in 2.1 already. i only tested with the default version, which is 2.0.2 here (the last version before 2.1 ;-) ). well... at least you have a bug report closed now. ;-) Compiler errors display as INFO level messages -- Key: MCOMPILER-87 URL: https://jira.codehaus.org/browse/MCOMPILER-87 Project: Maven 2.x Compiler Plugin Issue Type: Bug Environment: Ubuntu 8.04 64-bit, Maven version: 2.0.8, Java version: 1.6.0_10 OS name: linux version: 2.6.21.7-2.fc8xen arch: amd64 Family: unix Reporter: Dang Nguyen Assignee: Mark Struberg When a compile failure occurs, the exception(s) that causes the compile failure is displayed as an INFO level message. Only the final message that reads BUILD FAILURE is displayed as an ERROR level message. The exception stack should also be ERROR level messages. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT - Key: MRELEASE-699 URL: https://jira.codehaus.org/browse/MRELEASE-699 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Geoffrey De Smet The documentation http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html states The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used. That's not true, as releaseVersion is not supported: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion This means, that if you do this: mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274900#comment-274900 ] Geoffrey De Smet commented on MRELEASE-699: --- I patched this, please pull my changes: https://github.com/apache/maven-release/pull/2 This fix also fixes the fact that RewritePomVersionsPhase.getOriginalVersionMap() was inaccurate (although that did not seem to have any bad effect). release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT - Key: MRELEASE-699 URL: https://jira.codehaus.org/browse/MRELEASE-699 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Geoffrey De Smet The documentation http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html states The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used. That's not true, as releaseVersion is not supported: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion This means, that if you do this: mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-86) Using JDK 1.5 causes ParseException: Can't use generics unless running in JDK 1.5 mode!
[ https://jira.codehaus.org/browse/MPMD-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274907#comment-274907 ] Scott MacDonald commented on MPMD-86: - The workaround of setting propertiestargetJdk1.6targetJdkproperties is not working for me. This bug still exists in latest maven 3.0.03 PMD 2.4, has a workaround that does not work in all cases, and should be reopened. Using JDK 1.5 causes ParseException: Can't use generics unless running in JDK 1.5 mode! --- Key: MPMD-86 URL: https://jira.codehaus.org/browse/MPMD-86 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.4 Environment: JAVA 1.5, Maven 2.0.9 Reporter: Debabrat Panda Assignee: Benjamin Bentmann While running PMD with Maven i am getting parsing error Error while parsing ../../../java file The errors are 1. Can't use generics unless running in JDK 1.5 mode! 2. Can't use static imports when running in JDK 1.4 mode! Can't use annotations when running in JDK 1.4 mode! Any help will be appreciated. Thanks in advance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5146) parent.relativePath Warning is very misleading
parent.relativePath Warning is very misleading -- Key: MNG-5146 URL: https://jira.codehaus.org/browse/MNG-5146 Project: Maven 2 3 Issue Type: Bug Components: Errors Environment: Maven 3.0.3 Reporter: Scott MacDonald Priority: Minor When a parent pom.xml is located in a sibling directory as the children, and relativePath is not set in the parent element of the children, maven spits out a completely bogus, very misleading, warning message. For example, suppose com.fubar and com.parent are in sibling directories (along with a bunch of other modules), and com.fubar specifies com.parent as its parent, but does snot specify a parent.relativePath in it parent element. When you run a build, you get the following... [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for com.fubar:jar:1234.5 [WARNING] 'parent.relativePath' points at com.someRandomModule instead of com.parent, please verify your project structure @ line 10, column 11 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] The warning incorrectly states that the child pom has specified com.someRandomModule (a completely unrelated module) as its parent when that is completely not the case. The unlreated module, in this case, happens to be an existing module in a differrnt sibling directory, but otherwise has no relation whatsoever to the parent or child. It would be much better to warn about the actual problem The actual problem is that maven first tries to resolve parent poms locally based on the value of relativePath in the parent element of the child. IF it does not find it there, it will then resolve the parent from the repos. The current default value of relativepath is ../pom.xml (which in my case doesn;t work because my parent is in a sibling directory) The warning should be changed to something useful, such as [WARNING] Could not resolve parent pom locally using parent.relativePath value of ../pom.xml. Parent pom will be resolved from local or remote repository. To disable local parent pom resolution, specify relativePathrelativePath in you parent element. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MPOM-23) move maven-site-plugin configuration for Maven 3 from maven-parent to asf-parent
[ https://issues.apache.org/jira/browse/MPOM-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078970#comment-13078970 ] Hudson commented on MPOM-23: Integrated in ASF Parent Pom #28 (See [https://builds.apache.org/job/ASF%20Parent%20Pom/28/]) [MPOM-23] forgot ssh wagon provider for m-site-p (got a nice error message as expected :) ) [MPOM-23] upgraded maven-site-plugin to 3.0 both for Maven 2 3 hboutemy : http://svn.apache.org/viewvc/?view=revrev=1153631 Files : * /maven/pom/trunk/asf/pom.xml hboutemy : http://svn.apache.org/viewvc/?view=revrev=1153622 Files : * /maven/pom/trunk/asf/pom.xml move maven-site-plugin configuration for Maven 3 from maven-parent to asf-parent Key: MPOM-23 URL: https://issues.apache.org/jira/browse/MPOM-23 Project: Maven POMs Issue Type: Wish Components: asf, maven Affects Versions: MAVEN-20, ASF-9 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: MAVEN-21, ASF-10 ssh wagon dependency was added in MPOM-19 and site.xml attachement is missing from asf -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274925#comment-274925 ] Brett Porter commented on MRELEASE-699: --- Would you mind attaching it as a patch to JIRA? We can't use the github feature directly. Thanks! release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT - Key: MRELEASE-699 URL: https://jira.codehaus.org/browse/MRELEASE-699 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Geoffrey De Smet The documentation http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html states The update-versions goal can use the same properties used by the prepare goal for specifying the versions to be used. That's not true, as releaseVersion is not supported: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion This means, that if you do this: mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-582) Make it possible to remove breadcrumbs in child projects again
[
https://jira.codehaus.org/browse/MSITE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274929#comment-274929
]
Herve Boutemy commented on MSITE-582:
-
I understand the issue
but I don't understand the proposal: simply use the child's breadcrumbs
wholesale whenever they are a prefix to the parents
so the child could only go back to an existing breadcrumb, but not add its own
item?
Pehaps we should remove remaining breadcrumbs entries when one existing
breadcrumb is in the child, then continue
this would permit to remove some trailing items from parent, while still adding
new ones for child
Make it possible to remove breadcrumbs in child projects again
--
Key: MSITE-582
URL: https://jira.codehaus.org/browse/MSITE-582
Project: Maven 2.x and 3.x Site Plugin
Issue Type: New Feature
Components: inheritance
Affects Versions: 3.0
Reporter: Andreas Sewe
Attachments: example.tar.gz
Currently a child can only add more breadcrumbs. There are situations,
however, where it is desirable to remove some or all of the breadcrumbs
defined by the parent, in particular when the Maven project hierarchy doesn't
match the _natural_ hierarchy of the site. See
http://www.mail-archive.com/users@maven.apache.org/msg117974.html for an
example (also attached).
One way to do this, without requiring changes to the {{site.xml}} format and
with only minimal breakage of compatibility, would be to simply use the
child's breadcrumbs wholesale whenever they are a prefix to the parents.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4687) Maven should not warn about incorrect parent path when no relativePath is specified
[
https://jira.codehaus.org/browse/MNG-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274931#comment-274931
]
Laird Nelson commented on MNG-4687:
---
No, please do not do automatic local resolution.
In a large project where pom.xml changes are made relatively frequently,
sometimes users do not do, say, an {{svn update}}. In such a case a local
build will reference what is effectively an out-of-date pom. If automatic
filesystem resolution were turned on, there would be no way to force Maven to
go get the pom from the repo. Unless, of course, I'm missing something.
Maven should not warn about incorrect parent path when no relativePath is
specified
---
Key: MNG-4687
URL: https://jira.codehaus.org/browse/MNG-4687
Project: Maven 2 3
Issue Type: Improvement
Components: Logging
Affects Versions: 3.0-beta-1
Reporter: Paul Gier
Priority: Minor
Attachments: MNG-relativePath.zip
If a module pom uses a parent other than the one in the parent directory,
maven logs a warning. In some cases it is necessary that a module pom has an
external parent pom, and there is no way to refer to this external pom in the
relativePath. If nothing is specified in the relativePath, Maven should not
log the warning.
{noformat}
[WARNING] 'parent.relativePath' of POM
org.maven.test:relative-path-parent:0.0.1-SNAPSHOT
(/home/pgier/projects/MNG-relativePath/module-1/pom.xml) points at
org.maven.test:relative-path-test instead of org.apache.maven:maven-parent,
please verify your project structure @
{noformat}
The attached zip reproduces the warning.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5147) Validation strict mode
Validation strict mode -- Key: MNG-5147 URL: https://jira.codehaus.org/browse/MNG-5147 Project: Maven 2 3 Issue Type: New Feature Affects Versions: 3.0.3 Reporter: Brett Porter Maven 3 currently prints a number of deprecation / best practices warning at the start of the build for things that need to be improved and may not be supported in the future. These can pass by without being noticed since they are at the start, or be easily ignored. It would be good to have a way to fail the build if they exist. A command line option --strict is a potential solution, though it would be better to be able to set it permanently (e.g. via MAVEN_OPTS or settings.xml) - so a property might be another alternative. Another possibility is exposing it in a way that an Enforcer rule can be crafted so that it can be set on a per-project basis. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
