[jira] Created: (MDEP-290) purge-local-repository fails when the dependency was never download yet and copying is declared
purge-local-repository fails when the dependency was never download yet and copying is declared --- Key: MDEP-290 URL: http://jira.codehaus.org/browse/MDEP-290 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: purge-local-repository Affects Versions: 2.1 Reporter: Dieter König Assignee: Brian Fox Using goal "purge-local-repository" together with "copy-dependencies" leads to failure of build with "dependency is missing" if one of the declared snapshot-dependencies was never downloaded before. Example, pom.xml: ... some.groupid some.artifactid 1.0-SNAPSHOT org.apache.maven.plugins maven-dependency-plugin 2.1 clean-local-repository prepare-package purge-local-repository false true copy-artifact package copy-dependencies some.artifactid ... In the local maven repository the folder "some.artifactid" should be missing (just delete it manually if you are testing with something which you already have there). Now try to build the project with the given pom. It will fail with the message that dependency is missing. If you comment out the execution of purge-local-repository the build will run successfully (maven downloads the declared dependency). Otherwise if you comment out the execution of copy-dependencies the build will also run successfully. But if you have both executions together declared it will fail as long as the declared dependency is not in the local repository... -- 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-524) command line versions don't seem to work on release:branch for specific format
[ http://jira.codehaus.org/browse/MRELEASE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=239985#action_239985 ] Christoph Kutzinski commented on MRELEASE-524: -- Thanks, seems to work now. However, the documentation on http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html is a little bit misleading as it doesn't mention the updateBranchVersions parameter which you have to use. Otherwise the .rel parameters will have no effect. I.e. mvn --batch-mode release:branch -DbranchName=my-branch-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \ -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT should read: mvn --batch-mode release:branch -DupdateBranchVersions=true -DbranchName=my-branch-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \ -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT > command line versions don't seem to work on release:branch for specific > format > > > Key: MRELEASE-524 > URL: http://jira.codehaus.org/browse/MRELEASE-524 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0 > Environment: maven 2.2.1 >Reporter: Max Schaefer >Assignee: Brett Porter > Fix For: 2.1 > > Attachments: MRELEASE-524-batch-mode(2).patch, > MRELEASE-524-batch-mode.patch > > > I have tried passing versions for certain modules to the command line while > making a branch. The plugin ignores my parameters when running > release:branch. It injects the defaults if I pass parameters in batch mode. > E.g. this command taken from the documentation does not work. > mvn --batch-mode release:branch -DbranchName=my-branch-1.2 > -Dproject.rel.org.myCompany:projectA=1.2 \ > -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT > release:prepare supports this specific format for setting these values at > command line. > Setting these values in a release.properties file e.g. > project.dev.org.myCompany\:projectA=2.0-SNAPSHOT > project.rel.org.myCompany\:projectA=1.2 > works also fine. > Specifying the default at commandline works also e.g. > mvn --batch-mode release:branch -DbranchName=my-branch-1.2 > -DreleaseVersion=1.2 \ > -DdevelopmentVersion=2.0-SNAPSHOT -- 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-524) command line versions don't seem to work on release:branch for specific format
[ http://jira.codehaus.org/browse/MRELEASE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=239986#action_239986 ] Christoph Kutzinski commented on MRELEASE-524: -- BTW: is it also possible to specify the versions in a release.properties file or can they only be passed as command line parameters? > command line versions don't seem to work on release:branch for specific > format > > > Key: MRELEASE-524 > URL: http://jira.codehaus.org/browse/MRELEASE-524 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0 > Environment: maven 2.2.1 >Reporter: Max Schaefer >Assignee: Brett Porter > Fix For: 2.1 > > Attachments: MRELEASE-524-batch-mode(2).patch, > MRELEASE-524-batch-mode.patch > > > I have tried passing versions for certain modules to the command line while > making a branch. The plugin ignores my parameters when running > release:branch. It injects the defaults if I pass parameters in batch mode. > E.g. this command taken from the documentation does not work. > mvn --batch-mode release:branch -DbranchName=my-branch-1.2 > -Dproject.rel.org.myCompany:projectA=1.2 \ > -Dproject.dev.org.myCompany:projectA=2.0-SNAPSHOT > release:prepare supports this specific format for setting these values at > command line. > Setting these values in a release.properties file e.g. > project.dev.org.myCompany\:projectA=2.0-SNAPSHOT > project.rel.org.myCompany\:projectA=1.2 > works also fine. > Specifying the default at commandline works also e.g. > mvn --batch-mode release:branch -DbranchName=my-branch-1.2 > -DreleaseVersion=1.2 \ > -DdevelopmentVersion=2.0-SNAPSHOT -- 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: (MEV-603) easyconf-0.9.5 is referencing missing artifacts
[ http://jira.codehaus.org/browse/MEV-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juven Xu closed MEV-603. Resolution: Incomplete Assignee: Juven Xu We don't change dependencies in POMs already in the repository anymore as builds need to be reproducible. > easyconf-0.9.5 is referencing missing artifacts > --- > > Key: MEV-603 > URL: http://jira.codehaus.org/browse/MEV-603 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Aleksandr Tarutin >Assignee: Juven Xu > > Missing dependencies from POM: > > xdoclet > xdoclet > 1.2.1 > > > xdoclet > xdoclet-web-module > 1.2.1 > > > xpp3 > xpp3_min > 1.1.3.4.I > > As a workaround, it is possible to add the following dependencies to the > project's POM: > > > xdoclet > xdoclet > 1.2.3 > > > > xdoclet > xdoclet-web-module > 1.2.3 > > > > xpp3 > xpp3_min > 1.1.3.4.O > -- 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: (MASSEMBLY-514) The value for prerequisites/maven in the pom.xml should be 2.2.1 for Maven Assembly Plugin 2.2
The value for prerequisites/maven in the pom.xml should be 2.2.1 for Maven
Assembly Plugin 2.2
--
Key: MASSEMBLY-514
URL: http://jira.codehaus.org/browse/MASSEMBLY-514
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Guillaume Husta
Priority: Minor
The 2.2 version of the Assembly Plugin doesn't work with Maven 2.0.11.
The pom.xml indicates :
{code:xml}
2.0.11
1.1.2
2.2.1
true
{code}
When I invoke the 'single' goal (jar-with-dependencies) in the package phase of
a module, I get an error when working with Maven 2.0.11.
It seems to already have been fixed in the next version.
See :
[http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/pom.xml?r1=1021399&r2=1021398&pathrev=1021399]
--
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-4869) Parent POM is not evaluated as expected, regression in Maven 3
Parent POM is not evaluated as expected, regression in Maven 3
--
Key: MNG-4869
URL: http://jira.codehaus.org/browse/MNG-4869
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
Reporter: Joern Huxhorn
Priority: Critical
We have the following situation in our project:
A parent pom containing the following infos:
6.1.9
org.mortbay.jetty
maven-jetty-plugin
${jettyVersion}
A child module with the following configuration:
org.mortbay.jetty
maven-jetty-plugin
org.mortbay.jetty
jetty-plus
${jettyVersion}
org.mortbay.jetty
jetty-naming
${jettyVersion}
The property jettyVersion was added during the latest. The parent pom is the
first sub-module in the master pom, followed by the other sub-modules including
the child-module above. All definitions include correct
entries.
Previously, it worked perfectly well to simply build the master pom, which in
turn built the parent followed by all other sub-modules.
Since Maven 3, however, this didn't work anymore. Right after the addition of
the jettyVersion property, Maven 3 complained with the following error:
[ERROR] The build could not read 24 projects -> [Help 1]
[ERROR]
[ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
'${jettyVersion}'. @ line 28, column 28
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
'${jettyVersion}'. @ line 33, column 28
Building the parent manually fixed this issue.
To be precise, our actual project involved another parent level, i.e. the
parent described above was the parent of parent2 while parent2 was the parent
of the child module - but I don't think that this is relevant. I'm just
mentioning it just in case. Again, all definitions include correct
entries.
This worked in Maven 2 so I think it's a regression.
--
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-4869) Parent POM is not evaluated as expected, regression in Maven 3
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4869.
--
Resolution: Cannot Reproduce
Assignee: Benjamin Bentmann
> Parent POM is not evaluated as expected, regression in Maven 3
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Assignee: Benjamin Bentmann
>Priority: Critical
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> A child module with the following configuration:
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-4869) Parent POM is not evaluated as expected, regression in Maven 3
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4869:
---
Attachment: MNG-4869.zip
>From the information given, I'm not able to reproduce the issue using the
>attached example project. So please re-open with a complete/runnable project
>that exhibits the problem and allows its analysis.
> Parent POM is not evaluated as expected, regression in Maven 3
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Critical
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> A child module with the following configuration:
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-640) org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
[ http://jira.codehaus.org/browse/SUREFIRE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=239998#action_239998 ] Michal Galet commented on SUREFIRE-640: --- Hi, I have the same problem. When I set *redirectTestOutputToFile* to true the build fails with this Error. It happens for both Maven 2.2.1 and 3.0.0 using surefire plugin 2.6. > org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: > Error inside systemErr parser > --- > > Key: SUREFIRE-640 > URL: http://jira.codehaus.org/browse/SUREFIRE-640 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 2.2.1 >Reporter: Michael Hinterseher >Priority: Minor > > Since update to Surefire 2.6 our CI server is breaking builds every now and > then with: > ... > Results : > Tests run: 42, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error while executing forked tests.; nested exception is > org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: > Error inside systemErr parser > [INFO] > > [INFO] For more information, run Maven with the -e switch > ... > Up to now I was not able to reproduce the issue. It looks like a concurrency > issue. > Configuration: > > > > target/cobertura/cobertura.ser > > true > > > true > > Probably due to 42 tests ;-) -- 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] Reopened: (MNG-4702) MavenProject.getActiveProfiles() does not merge active profiles from parent POMs
[
http://jira.codehaus.org/browse/MNG-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Corneliussen reopened MNG-4702:
I still think there is an issue here... Sorry :(
> MavenProject.getActiveProfiles() does not merge active profiles from parent
> POMs
>
>
> Key: MNG-4702
> URL: http://jira.codehaus.org/browse/MNG-4702
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.2.1, 3.0-beta-1
>Reporter: Lars Corneliussen
>Assignee: Benjamin Bentmann
> Attachments: buggy-profiles.zip
>
>
> Profiles from parent pom's are internally merged, but getActiveProfiles()
> doesn't return them as long as they aren't redefined in the module.
> The zip contains two poms with some profiles:
> buggy-profiles (activate-me, active-by-default, shared-profile)
> + buggy-module (module-activate-me, module-active-by-default, shared-profile)
> Each of the profiles adds a "echo ..." to the validate-phase.
> {code:title=mvn validate help:active-profiles}
>
> Building buggy-pom 1.0-SNAPSHOT
>
> --- exec-maven-plugin:1.1:exec (active-by-default) @ buggy-pom ---
> "### running 'active-by-default'"
>
> Building buggy-module 1.0-SNAPSHOT
>
> --- exec-maven-plugin:1.1:exec (active-by-default) @ buggy-module ---
> "### running 'active-by-default'"
> --- exec-maven-plugin:1.1:exec (module-active-by-default) @ buggy-module ---
> "### running 'module-active-by-default'"
> ..
> ..
> Active Profiles for Project 'test:buggy-pom:pom:1.0-SNAPSHOT':
> The following profiles are active:
> - active-by-default (source: pom)
> - netcologne.default (source: settings.xml)
> Active Profiles for Project 'test:buggy-module:pom:1.0-SNAPSHOT':
> The following profiles are active:
> - module-active-by-default (source: pom)
> - netcologne.default (source: settings.xml)
> {code}
> The module should also list 'active-by-default'. Even more since it is also
> run correctly.
> Explicitely activated profiles behave the same:
> {code}mvn validate help:active-profiles -P activate-me,
> module-activate-me{code}
> When the a profile is redefined in the module (without any changes) the
> active-profiles list is correct:
> {code}
> {code}mvn validate help:active-profiles -P activate-me,
> module-activate-me{code}
--
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] Reopened: (MNG-4869) Parent POM is not evaluated as expected, regression in Maven 3
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joern Huxhorn reopened MNG-4869:
You are right, the original description missed a crucial piece of information
that I just discovered:
The parent-version requested in the child pom was different from the version as
defined in the parent pom itself, i.e. the parent had
1.0-SNAPSHOT while the child requested
2.0-SNAPSHOT.
This mistake didn't hurt in Maven 2 since (I guess) the parent version was
ignored in the presence of a valid relativePath. This seems to have changed in
Maven 3, which is actually ok/correct.
I tentatively reopened this issue anyway since I think that Maven 3 should
warn/fail in such a situation. This obviously isn't a critical issue anymore,
though.
Please let me know how we should handle this. Should I file a new issue
(feature request) or will you change this one accordingly?
Interestingly, the title isn't that incorrect after all...
> Parent POM is not evaluated as expected, regression in Maven 3
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Assignee: Benjamin Bentmann
>Priority: Critical
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> A child module with the following configuration:
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4869:
---
Component/s: POM
Description:
We have the following situation in our project:
A parent pom containing the following infos:
{code:xml}
6.1.9
org.mortbay.jetty
maven-jetty-plugin
${jettyVersion}
{code}
A child module with the following configuration:
{code:xml}
org.mortbay.jetty
maven-jetty-plugin
org.mortbay.jetty
jetty-plus
${jettyVersion}
org.mortbay.jetty
jetty-naming
${jettyVersion}
{code}
The property jettyVersion was added during the latest. The parent pom is the
first sub-module in the master pom, followed by the other sub-modules including
the child-module above. All definitions include correct
entries.
Previously, it worked perfectly well to simply build the master pom, which in
turn built the parent followed by all other sub-modules.
Since Maven 3, however, this didn't work anymore. Right after the addition of
the jettyVersion property, Maven 3 complained with the following error:
{noformat}
[ERROR] The build could not read 24 projects -> [Help 1]
[ERROR]
[ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
'${jettyVersion}'. @ line 28, column 28
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
'${jettyVersion}'. @ line 33, column 28
{noformat}
Building the parent manually fixed this issue.
To be precise, our actual project involved another parent level, i.e. the
parent described above was the parent of parent2 while parent2 was the parent
of the child module - but I don't think that this is relevant. I'm just
mentioning it just in case. Again, all definitions include correct
entries.
This worked in Maven 2 so I think it's a regression.
was:
We have the following situation in our project:
A parent pom containing the following infos:
6.1.9
org.mortbay.jetty
maven-jetty-plugin
${jettyVersion}
A child module with the following configuration:
org.mortbay.jetty
maven-jetty-plugin
org.mortbay.jetty
jetty-plus
${jettyVersion}
org.mortbay.jetty
jetty-naming
${jettyVersion}
The property jettyVersion was added during the latest. The parent pom is the
first sub-module in the master pom, followed by the other sub-modules including
the child-module above. All definitions include correct
entries.
Previously, it worked perfectly well to simply build the master pom, which in
turn built the parent followed by all other sub-modules.
Since Maven 3, however, this didn't work anymore. Right after the addition of
the jettyVersion property, Maven 3 complained with the following error:
[ERROR] The build could not read 24 projects -> [Help 1]
[ERROR]
[ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
'${jettyVersion}'. @ line 28, column 28
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
'${jettyVersion}'. @ line 33, column 28
Building the parent manually fixed this issue.
To be precise, our actual project involved another parent level, i.e. the
parent described above was the parent of parent2 while parent2 was the parent
of the child module - but I don't think that this is relevant. I'm just
mentioning it just in case. Again, all definitions include correct
entries.
This worked in Maven 2 so I think it's a regression.
Priority: Trivial (was: Critical)
Issue Type: Improvement (was: Bug)
Summary: Warn when relativePath points at parent POM with different
version (was: Parent POM is not evaluated as expected, regression in Maven 3)
bq. This mistake didn't hurt in Maven 2 since (I guess) the parent version was
ignored in the presenc
[jira] Updated: (MNG-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4869:
---
Assignee: (was: Benjamin Bentmann)
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240017#action_240017
]
Joern Huxhorn commented on MNG-4869:
Ok, I see.
The MNG-4619 feature did actually help me already while migrating from Maven 2
to Maven 3. I liked it a lot. The enhanced diagnostic messages are the main
Maven 3 feature for me, at least for now.
I think, but that's of course only my opinion, that a version mismatch in the
presence of a relative path is at least somewhat strange. It would probably be
a case for some "I really mean it" marker for the parent version or an option
to disable such a check.
In our 360 module project such a situation would always be a mistake. But
others might use Maven differently.
Otherwise an issue like the one that bit me is pretty hard to diagnose,
especially since the behavior changed from Maven 2. I double- and
triple-checked the relative path but overlooked the version issue repeatedly.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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: (DOXIA-415) Doxia rejects/rewrites intentional relative http: link in APT
Doxia rejects/rewrites intentional relative http: link in APT
-
Key: DOXIA-415
URL: http://jira.codehaus.org/browse/DOXIA-415
Project: Maven Doxia
Issue Type: Bug
Components: Module - Apt
Affects Versions: 1.1
Reporter: Benson Margulies
I wrote:
{code}
{{{http:./jdd/index.html}A Link}}
{code}
Because I know that there is going to be such a page by the time my output is
deployed. I expected the http: to cause Doxia to 'butt out'. Instead, I get:
[WARNING] [APT Parser] Modified invalid link: 'http:./jdd/index.html' to
'#http:.jddindex.html'
[WARNING] [APT Parser] Ambiguous link: 'http:./jdd/index.html'. If this is a
local link, prepend "./"!
Notice that I DID prepend ./. Taking out the ./ doesn't help.
--
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-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240018#action_240018
]
Joern Huxhorn commented on MNG-4869:
I just read that the behavior didn't change in Maven 3. Sure? I had the
impression that the parent pom at the relative path was always taking
precedence over poms from the local repository.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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: (SCM-580) Maven SCM plugin configuration ignored if executions are used.
Maven SCM plugin configuration ignored if executions are used.
--
Key: SCM-580
URL: http://jira.codehaus.org/browse/SCM-580
Project: Maven SCM
Issue Type: Bug
Affects Versions: 1.4
Environment: Windows
Reporter: Lee Fox
When utilizing the embedded configuration tag, everything is perfect. However,
once I try to use executions, the plugin fails to recognize the settings
specified in within the execution tag. Here is the portion of my pom file that
doesn't work:
bootstrap-all
true
org.apache.maven.plugins
maven-scm-plugin
1.4
checkout_a
scm:svn:https://svnserver/svn/prod/java/aws-core-webutils/trunk/
${basedir}..\aws-core-webutils
process-resources
checkout
However, this does work:
bootstrap-all
true
org.apache.maven.plugins
maven-scm-plugin
1.4
scm:svn:https://svnserver/svn/prod/java/aws-core-webutils/trunk/
${basedir}\..\aws-core-webutils
--
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-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240021#action_240021
]
Benjamin Bentmann commented on MNG-4869:
No offense but seriously, despite some rumors, Maven is a build tool, not some
esoteric box, i.e. there is little point in talking about impressions. All that
matters are logs and reproducible examples, otherwise we end up talking about
thin air. So, taking the example project I provided and changing
{{child/pom.xml}} to inherit from {{parent2:1.1-SNAPSHOT}}, I see both Maven
2.x and 3.x failing to locate the parent (assuming version 1.1-SNAPSHOT wasn't
installed to the local repo before). Yes, there are some changes regarding
parent resolution, but I fail to see how those affect the example project or
for that matter your setup (which I don't know but can only guess).
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240024#action_240024
]
Joern Huxhorn commented on MNG-4869:
I didn't mean to imply you were wrong.
Instead I obviously had the wrong impression all the time. If my last comment
sounded offensive it definitely wasn't meant to do so. I was merely surprised.
Thanks for taking the time to analyze this.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240030#action_240030
]
Benjamin Bentmann commented on MNG-4869:
bq, If my last comment sounded offensive it definitely wasn't meant to do so. I
was merely surprised.
No worries, I got that. All I was trying is to highlight is the importance of
logs and reproducible examples, i.e. concrete data points. I am still surprised
how many people fill bugs or ask for help with troubleshooting their build
issues without enabling others to reproduce/analyze the issue. Efficient
communication is the art of eliminating guess work.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
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-4870) dependency:tree omits batik-js
dependency:tree omits batik-js
--
Key: MNG-4870
URL: http://jira.codehaus.org/browse/MNG-4870
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0
Environment: Maven 3.0, Ubuntu, JDK 6.
Reporter: Jesse Glick
Attachments:
test_test-dependency-tree_jar_1.0-SNAPSHOT_101018-185145.zip
(Not sure what the right place to file this is. {{maven-dependency-tree 1.2}}
gives {{MNG}} as the JIRA component by inheritance.)
{{mvn dependency:tree}} on the attached project lists {{batik-script}} by way
of {{batik-bridge}} as expected, but then fails to show {{batik-js}} as a
dependency of that. If you list {{batik-script}} as a direct dependency,
{{batik-js}} is correctly shown.
Possibly related is that Maven 2.2.1 also fails to find {{batik-js}} in
{{MavenProject.getRuntimeArtifacts}}, so {{clean package}} fails, whereas this
works fine under Maven 3.0. Yet just running the dependency plugin under M3
does not suffice to pick up this fix, wherever it was - MNG-4690?
Although the Batik JARs are built from an odd source tree, the artifacts as
present in the local repository look normal enough; all of the dependencies
involved are simple compile scope without exclusions etc.
Marking "major" since this seems to cause MNBMODULE-102 (producing build errors
for certain projects); also I have noticed that the dependency graph feature in
the NB IDE omits {{batik-js}}, and there may be other user-visible effects of
this bug.
--
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] Moved: (MSHARED-167) dependency:tree omits batik-js
[
http://jira.codehaus.org/browse/MSHARED-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4870 to MSHARED-167:
Complexity: (was: Intermediate)
Component/s: (was: Dependencies)
maven-dependency-tree
Affects Version/s: (was: 3.0)
maven-dependency-tree 1.2
Key: MSHARED-167 (was: MNG-4870)
Project: Maven Shared Components (was: Maven 2 & 3)
> dependency:tree omits batik-js
> --
>
> Key: MSHARED-167
> URL: http://jira.codehaus.org/browse/MSHARED-167
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-tree
>Affects Versions: maven-dependency-tree 1.2
> Environment: Maven 3.0, Ubuntu, JDK 6.
>Reporter: Jesse Glick
> Attachments:
> test_test-dependency-tree_jar_1.0-SNAPSHOT_101018-185145.zip
>
>
> (Not sure what the right place to file this is. {{maven-dependency-tree 1.2}}
> gives {{MNG}} as the JIRA component by inheritance.)
> {{mvn dependency:tree}} on the attached project lists {{batik-script}} by way
> of {{batik-bridge}} as expected, but then fails to show {{batik-js}} as a
> dependency of that. If you list {{batik-script}} as a direct dependency,
> {{batik-js}} is correctly shown.
> Possibly related is that Maven 2.2.1 also fails to find {{batik-js}} in
> {{MavenProject.getRuntimeArtifacts}}, so {{clean package}} fails, whereas
> this works fine under Maven 3.0. Yet just running the dependency plugin under
> M3 does not suffice to pick up this fix, wherever it was - MNG-4690?
> Although the Batik JARs are built from an odd source tree, the artifacts as
> present in the local repository look normal enough; all of the dependencies
> involved are simple compile scope without exclusions etc.
> Marking "major" since this seems to cause MNBMODULE-102 (producing build
> errors for certain projects); also I have noticed that the dependency graph
> feature in the NB IDE omits {{batik-js}}, and there may be other user-visible
> effects of this bug.
--
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: (MSHARED-167) dependency:tree omits batik-js
[
http://jira.codehaus.org/browse/MSHARED-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240036#action_240036
]
Benjamin Bentmann commented on MSHARED-167:
---
The tree calculated by Maven 3.0 core is correct:
{noformat}
[DEBUG] test:test-dependency-tree:jar:1.0-SNAPSHOT
[DEBUG]org.apache.xmlgraphics:batik-swing:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-bridge:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-parser:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-script:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-js:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-xml:jar:1.7:compile
[DEBUG] xalan:xalan:jar:2.6.0:compile
[DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-ext:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-gui-util:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-gvt:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:compile
[DEBUG] xml-apis:xml-apis:jar:1.3.04:compile
[DEBUG] xml-apis:xml-apis-ext:jar:1.3.04:compile
{noformat}.
As mentioned in the compat notes, {{maven-dependency-tree}} couldn't be briged
onto Aether and this is one of those corner cases where the discrepancy gets
visible.
> dependency:tree omits batik-js
> --
>
> Key: MSHARED-167
> URL: http://jira.codehaus.org/browse/MSHARED-167
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-tree
>Affects Versions: maven-dependency-tree 1.2
> Environment: Maven 3.0, Ubuntu, JDK 6.
>Reporter: Jesse Glick
> Attachments:
> test_test-dependency-tree_jar_1.0-SNAPSHOT_101018-185145.zip
>
>
> (Not sure what the right place to file this is. {{maven-dependency-tree 1.2}}
> gives {{MNG}} as the JIRA component by inheritance.)
> {{mvn dependency:tree}} on the attached project lists {{batik-script}} by way
> of {{batik-bridge}} as expected, but then fails to show {{batik-js}} as a
> dependency of that. If you list {{batik-script}} as a direct dependency,
> {{batik-js}} is correctly shown.
> Possibly related is that Maven 2.2.1 also fails to find {{batik-js}} in
> {{MavenProject.getRuntimeArtifacts}}, so {{clean package}} fails, whereas
> this works fine under Maven 3.0. Yet just running the dependency plugin under
> M3 does not suffice to pick up this fix, wherever it was - MNG-4690?
> Although the Batik JARs are built from an odd source tree, the artifacts as
> present in the local repository look normal enough; all of the dependencies
> involved are simple compile scope without exclusions etc.
> Marking "major" since this seems to cause MNBMODULE-102 (producing build
> errors for certain projects); also I have noticed that the dependency graph
> feature in the NB IDE omits {{batik-js}}, and there may be other user-visible
> effects of this bug.
--
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
