[jira] Updated: (MNG-3052) Transitive Dependency not found when repo is not listed
[ http://jira.codehaus.org/browse/MNG-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Olmes updated MNG-3052: Attachment: InheritLegacyRepo.zip This example does not exactly reproduce the described setup but illustrates the same effect. The toplevel pom defines a repository, module 'foo' defines two other repositories and module 'bar' depends on 'foo' and on artifacts that can be resolved from bar's repository. The point is here that if you define a dependency you should be able to resolve transient dependencies through the inherited repositories. > Transitive Dependency not found when repo is not listed > --- > > Key: MNG-3052 > URL: http://jira.codehaus.org/browse/MNG-3052 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre >Priority: Critical > Attachments: InheritLegacyRepo.zip > > > I have seen the situation where a build fails because a project has a > transitive dependency that only exists in a repository not listed by my > project. An example of this is I have Projects A, B, and C. Where A depends > on B, and B on C. B has been released to remote repo 1, and C has been > released to remote repo 2. Since A just directly depends on B it only lists > remote repo 1 in its POM. However when I try to build project A the build > fail because it can't resolve its transitive dependency C in any of the > dependencies it is checking (repo 1 only). > It is my understanding that for project A I shouldn't have to list the remote > repos to resolve transitive dependencies. I should only have to list the > repos to get to B and Maven then should use the POM of B to resolve C. > Is that not correct? -- 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-3468) FileSet needs a toString() method to properly print in debug mode
[
http://jira.codehaus.org/browse/MNG-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127851
]
Paul Benedict commented on MNG-3468:
Please update these 3 related tickets to 2.0.9 so they get on the release notes.
> FileSet needs a toString() method to properly print in debug mode
> -
>
> Key: MNG-3468
> URL: http://jira.codehaus.org/browse/MNG-3468
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: Wayne Fay
>Assignee: Brian Fox
> Fix For: 2.0.10
>
> Attachments: fileset.patch
>
>
> It would be nice if FileSet had a toString() method so it would print
> something intelligent rather than simply a memory location in debug mode.
> Before this change, it prints like:
> [EMAIL PROTECTED]
> With this patch, it prints like (assuming you accept my PatternSet patch):
> FileSet {directory: src/main/resources, PatternSet [includes: {}, excludes:
> {}]}
--
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-3469) Resource needs a toString() method to properly print in debug mode
[
http://jira.codehaus.org/browse/MNG-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3469.
--
Assignee: Brian Fox
Resolution: Fixed
Fix Version/s: 2.0.10
> Resource needs a toString() method to properly print in debug mode
> --
>
> Key: MNG-3469
> URL: http://jira.codehaus.org/browse/MNG-3469
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: Wayne Fay
>Assignee: Brian Fox
> Fix For: 2.0.10
>
> Attachments: resource.patch
>
>
> It would be nice if Resouce had a toString() method so it would print
> something intelligent rather than simply a memory location in debug mode.
> (People have complained about this on the Users list, and I've noticed it
> myself -- its annoying.)
> Before this change, it prints like:
> [EMAIL PROTECTED]
> With this patch, it prints like (assuming you accept my FileSet and
> PatternSet patches):
> Resource {targetPath: /target/resource-test, filtering: true, FileSet
> {directory: null, PatternSet [includes: {}, excludes: {}]}}
--
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-3468) FileSet needs a toString() method to properly print in debug mode
[
http://jira.codehaus.org/browse/MNG-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3468.
--
Assignee: Brian Fox
Resolution: Fixed
Fix Version/s: 2.0.10
> FileSet needs a toString() method to properly print in debug mode
> -
>
> Key: MNG-3468
> URL: http://jira.codehaus.org/browse/MNG-3468
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: Wayne Fay
>Assignee: Brian Fox
> Fix For: 2.0.10
>
> Attachments: fileset.patch
>
>
> It would be nice if FileSet had a toString() method so it would print
> something intelligent rather than simply a memory location in debug mode.
> Before this change, it prints like:
> [EMAIL PROTECTED]
> With this patch, it prints like (assuming you accept my PatternSet patch):
> FileSet {directory: src/main/resources, PatternSet [includes: {}, excludes:
> {}]}
--
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-3467) PatternSet needs a toString() method to properly print in debug mode
[
http://jira.codehaus.org/browse/MNG-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3467.
--
Resolution: Fixed
> PatternSet needs a toString() method to properly print in debug mode
>
>
> Key: MNG-3467
> URL: http://jira.codehaus.org/browse/MNG-3467
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: Wayne Fay
>Assignee: Brian Fox
> Fix For: 2.0.10
>
> Attachments: patternset.patch
>
>
> It would be nice if PatternSet had a toString() method so it would print
> something intelligent rather than simply a memory location in debug mode.
> Before this change, it prints like:
> [EMAIL PROTECTED]
> With this patch, it prints like:
> PatternSet [includes: {one, two}, excludes: {three, four}]
--
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-3467) PatternSet needs a toString() method to properly print in debug mode
[
http://jira.codehaus.org/browse/MNG-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3467:
---
Assignee: Brian Fox
Fix Version/s: 2.0.10
> PatternSet needs a toString() method to properly print in debug mode
>
>
> Key: MNG-3467
> URL: http://jira.codehaus.org/browse/MNG-3467
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.0.8
>Reporter: Wayne Fay
>Assignee: Brian Fox
> Fix For: 2.0.10
>
> Attachments: patternset.patch
>
>
> It would be nice if PatternSet had a toString() method so it would print
> something intelligent rather than simply a memory location in debug mode.
> Before this change, it prints like:
> [EMAIL PROTECTED]
> With this patch, it prints like:
> PatternSet [includes: {one, two}, excludes: {three, four}]
--
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-3286) execution.inherited field is ignored
[ http://jira.codehaus.org/browse/MNG-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3286. -- Resolution: Fixed > execution.inherited field is ignored > > > Key: MNG-3286 > URL: http://jira.codehaus.org/browse/MNG-3286 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.7 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > I have a plugin with multiple executions, one of them I only want to apply to > the parent. I set the execution.inherited=false, the execution is still run > on all the children. -- 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-3042) Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project.
[ http://jira.codehaus.org/browse/MNG-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127850 ] Andrew Lee Rubinger commented on MNG-3042: -- Would appreciate the implementation to use annotations with retention=RUNTIME. :) S, ALR > Extending a Mojo Class and used in a new Mojo Project, parameter fields in > the parent mojo are not set, this disables reuse of existing mojo project. > - > > Key: MNG-3042 > URL: http://jira.codehaus.org/browse/MNG-3042 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Reporter: Leopoldo Agdeppa III > Fix For: 2.1 > > > I have an Existing maven-plugin-a and I want to extend its functionality and > put it in maven-plugin-b, so what i did is I put the the maven-plugin-a as a > dependecy in maven-plugin-b and extended the mojo class from A, the issue on > this is that paramter fields from A is not set, when I used plugin-B, I think > this disables reusing and extending of mojos -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127848 ] Carlos Sanchez commented on MECLIPSE-405: - i know that issue and right now the only think you can do to work around it is explicitly set the versions in dependencymanagement (do it in the parent pom and it's a one time thing, see http://code.google.com/p/q4e/source/browse/branches/mavenbuild/pom.xml ). Stripping the qualifiers is a dirty hack. you can get a RC of 2.0.9 at http://people.apache.org/~brianf/staging-repository/org/apache/maven/apache-maven/2.0.9/ > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi >Assignee: Carlos Sanchez > Fix For: 2.5.1 > > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127847 ] partriv edited comment on MECLIPSE-405 at 3/18/08 6:32 PM: - You fixed it while i was still writing this. Thanks!! :) >although I encourage you to use the qualifier or you wont know what build of >eg 3.3.0 you are actually using That is actually the problem. So when the qualifiers are appended to the versions, artifact foo version 3.3.0-SomeQualifier doesnt resolve when artifact bar says foo [3.3.0,4.0.0) some Group... it cannot resolve foo, the error message returned is 'Couldn't find a version in [3.3.0-SomeQualifier] to match range [3.3.0,4.0.0).' from artifact bar. Does this make sense? I was told by someone in #maven that this happens because of the way versions are compared. Thanks. was (Author: partriv): >although I encourage you to use the qualifier or you wont know what build of eg 3.3.0 you are actually using That is actually the problem. So when the qualifiers are appended to the versions, artifact foo version 3.3.0-SomeQualifier doesnt resolve when artifact bar says foo [3.3.0,4.0.0) some Group... it cannot resolve foo, the error message returned is 'Couldn't find a version in [3.3.0-SomeQualifier] to match range [3.3.0,4.0.0).' from artifact bar. Does this make sense? I was told by someone in #maven that this happens because of the way versions are compared. Thanks. > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi >Assignee: Carlos Sanchez > Fix For: 2.5.1 > > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127847 ] Apaar Trivedi commented on MECLIPSE-405: >although I encourage you to use the qualifier or you wont know what build of >eg 3.3.0 you are actually using That is actually the problem. So when the qualifiers are appended to the versions, artifact foo version 3.3.0-SomeQualifier doesnt resolve when artifact bar says foo [3.3.0,4.0.0) some Group... it cannot resolve foo, the error message returned is 'Couldn't find a version in [3.3.0-SomeQualifier] to match range [3.3.0,4.0.0).' from artifact bar. Does this make sense? I was told by someone in #maven that this happens because of the way versions are compared. Thanks. > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi >Assignee: Carlos Sanchez > Fix For: 2.5.1 > > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-405. --- Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 2.5.1 Fixed, thanks although i stongly suggest you to use the qualifier ;) > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi >Assignee: Carlos Sanchez > Fix For: 2.5.1 > > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127844 ] Carlos Sanchez commented on MECLIPSE-405: - > When is Maven 2.0.9 being released? 1-2 weeks > Are you saying in maven 2.0.9+ this range issue will include 3.3.0.x in > [3.3.0-3.4.0)? That is a relief. no, it will allow you to use dependencyManagement for you to workaround it > Another issue I would like to mention is that you suggested on the mailing > list to use make-artifacts and I would like to note that the artifact id's it > provides are incorrect, which is the reason for its deprecation. For instance, make-artifacts will make an artifact with > This is the reason why we have not used make-artifacts to solve this problem. > Additionally, would it hurt to provide the stripQualifier as a parameter so > that people who are not using the eclipse nightly builds can still take > advantage of eclipse:to-maven while still using maven 2.0.8-? got it, parameters should be configurable in to-maven, but the defaults wont change, although I encourage you to use the qualifier or you wont know what build of eg 3.3.0 you are actually using > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127843 ] Apaar Trivedi commented on MECLIPSE-405: When is Maven 2.0.9 being released? Are you saying in maven 2.0.9+ this range issue will include 3.3.0.x in [3.3.0-3.4.0)? That is a relief. Another issue I would like to mention is that you suggested on the mailing list to use make-artifacts and I would like to note that the artifact id's it provides are incorrect, which is the reason for its deprecation. For instance, make-artifacts will make an artifact with groupId: org.eclipse.core and then call its artifact id org.eclipse.core.boot, when it should just be 'boot'. This is the reason why we have not used make-artifacts to solve this problem. Additionally, would it hurt to provide the stripQualifier as a parameter so that people who are not using the eclipse nightly builds can still take advantage of eclipse:to-maven while still using maven 2.0.8-? > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
[ http://jira.codehaus.org/browse/MECLIPSE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127841 ] Carlos Sanchez commented on MECLIPSE-405: - the qualifier is an important part of the version, it's not the same 3.3.0.x than 3.3.0.y so if Eclipse releases both versions we are not the people to strip it You can use dependencyManagement section to explicitly set the versions from Maven 2.0.9+ i've given a presentation at EclipseCON talking about this and other problems, will post them soon http://www.jroller.com/carlossg/entry/letters_from_eclipsecon > to-maven target should allow to strip qualifier when creating artifacts from > osgi bundles > - > > Key: MECLIPSE-405 > URL: http://jira.codehaus.org/browse/MECLIPSE-405 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.5 > Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 >Reporter: Apaar Trivedi > Attachments: to-mavenStringQualifier.patch > > > There is a problem with to-maven target which forces the user to append the > OSGI qualifiers to the artifact versions, thus making it impossible for > dependencies to resolve one another, due to the fact that the range specified > is not met with a version with a qualifier. > For instance, after mvn eclipse:to-maven is run, the eclipse plugins are > added into the repository. Many of them depend on each other, and their > dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency > provided ends up getting the version 3.3.0.-I20070403, i.e it has some > qualifier and so it does not match up, and therefore the dependencies do not > resolve and it all does not work. > The solution involves allowing the 'stripQualifier' parameter to be exposed > in the plugin, here is a note I sent to the dev list: > We need one thing parameterized on the EclipseToMavenMojo.java in the > maven-eclipse-plugin which should be parameterized anyway. In the call to > osgiVersionToMavenVersion, it only allows 'false' to be passed in for the > 'strip qualifier' parameter. > While the make-artifacts (which extends to-maven) target allows you to strip > the qualifier, this is not a parameter that can be used in the to-maven > target. This is a problem because using 'to-maven' provides artifacts with > the proper names and hierarchy, but the dependecies do not resolve due to the > qualifiers on the versions. While make-artifacts provides dependecies that > resolve but the naming convention of the groupId's and artifactId's is > incorrect, so this is also unacceptable, not to mention make-artifacts is > deprecated for this reason. > > Just a parameter -DstripQualifer that gets passed in to the call to > osgiVersionToMavenVersion( String version, String forcedQualifier, > boolean stripQualifier ) would be perfect. > I have included a patch which provides this parameter and uses it in the > necessary call to the method, while leaving its default value as false, thus > no functionality would change unless the parameter is used. Please consider > this asap, as it is stopping some work of ours here and I have had to modify > the source and install a fixed copy to my local repo to currently get around > this. > Thank you -- 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: (MECLIPSE-405) to-maven target should allow to strip qualifier when creating artifacts from osgi bundles
to-maven target should allow to strip qualifier when creating artifacts from osgi bundles - Key: MECLIPSE-405 URL: http://jira.codehaus.org/browse/MECLIPSE-405 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.5 Environment: Windows xp, regarding maven-eclipse-plugin, java 1.5 Reporter: Apaar Trivedi Attachments: to-mavenStringQualifier.patch There is a problem with to-maven target which forces the user to append the OSGI qualifiers to the artifact versions, thus making it impossible for dependencies to resolve one another, due to the fact that the range specified is not met with a version with a qualifier. For instance, after mvn eclipse:to-maven is run, the eclipse plugins are added into the repository. Many of them depend on each other, and their dependency is based on a range, for instance 3.3.0-3.4.0, but the dependency provided ends up getting the version 3.3.0.-I20070403, i.e it has some qualifier and so it does not match up, and therefore the dependencies do not resolve and it all does not work. The solution involves allowing the 'stripQualifier' parameter to be exposed in the plugin, here is a note I sent to the dev list: We need one thing parameterized on the EclipseToMavenMojo.java in the maven-eclipse-plugin which should be parameterized anyway. In the call to osgiVersionToMavenVersion, it only allows 'false' to be passed in for the 'strip qualifier' parameter. While the make-artifacts (which extends to-maven) target allows you to strip the qualifier, this is not a parameter that can be used in the to-maven target. This is a problem because using 'to-maven' provides artifacts with the proper names and hierarchy, but the dependecies do not resolve due to the qualifiers on the versions. While make-artifacts provides dependecies that resolve but the naming convention of the groupId's and artifactId's is incorrect, so this is also unacceptable, not to mention make-artifacts is deprecated for this reason. Just a parameter -DstripQualifer that gets passed in to the call to osgiVersionToMavenVersion( String version, String forcedQualifier, boolean stripQualifier ) would be perfect. I have included a patch which provides this parameter and uses it in the necessary call to the method, while leaving its default value as false, thus no functionality would change unless the parameter is used. Please consider this asap, as it is stopping some work of ours here and I have had to modify the source and install a fixed copy to my local repo to currently get around this. Thank you -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127837 ] Benjamin Bentmann commented on MECLIPSE-404: bq. On windows, I always saw /some/path to be resolved by default to c:\some\path. On Windows, a path like "/path" is known as a drive-relative path, i.e. its effective absolute value depends on your current working directory/drive. Run Maven on a project located somewhere on "C:" and your local repo is assumed to reside in "C:\path". Run Maven on a project located on drive "X:" and it will happily re-download the world to your other local repo at "X:\path" ;-) That's nothing which Maven specifically does, it's just blindly passing the user's config setting to the java.io.File API. bq. I guess that it would be far better for maven-eclipse-plugin to support this format since maven does, isn't it? The question is: Is the current behavior of Maven a bug or a feature? I am tempted to call it a missing validation of input parameters but have just mailed the dev list to get some clarification on this [path topic|http://www.nabble.com/Relative-path-to-local-repository--to16132131s177.html]. > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127829
]
Baptiste MATHUS commented on MECLIPSE-404:
--
{The first path being recognized as absolute, the later one as relative.}
On windows, I always saw /some/path to be resolved by default to c:\some\path.
You might be right about it. However that is not what maven understands.
On my config (WinXP), I put /path/to/repo a long time ago and maven always
understood c:\path\to\repo without the slightest warning.
I guess that it would be far better for maven-eclipse-plugin to support this
format since maven does, isn't it?
Cheers.
> Duplicated local repository path in the generated .classpath file
> -
>
> Key: MECLIPSE-404
> URL: http://jira.codehaus.org/browse/MECLIPSE-404
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.5
>Reporter: Baptiste MATHUS
>
> The generated .classpath is not correct.
> This problem seems to be related to using a non default repository location.
> In fact, if localRepository (in settings.xml) is the following:
> /path/to/repository
> Then all classpathentries in the .classpath file are generated as in the
> following example:
> M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> instead of
> M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> I can create a dedicated testcase project if necessary (if you have problem
> reproducing this issue) but I think this will be easy to reproduce by just
> testing with a non default repository location.
> Thanks a lot.
> Cheers.
--
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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127826 ] Will Hoover commented on MECLIPSE-404: -- Sounds like a plausible solution, but I would hardly consider what I was doing a hack or bug- I consider it more of a feature :o) All other operations in Maven can evaluate the path properly so I would hate to have something different just for this plug-in :o( > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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-3470) Build does not fail on corrupted POM even with checksumPolicy=fail
[
http://jira.codehaus.org/browse/MNG-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3470:
---
Attachment: mng-3470-it.patch
Attached failing IT.
Not sure how to fix this: {{getArtifact()}} swallows both {{TransferException}}
and {{ResourceNotFoundException}} to try other repos. But at the end, if
nothing worked, it needs to throw one of them but it is important to
distinguish which error occurred for the caller.
> Build does not fail on corrupted POM even with checksumPolicy=fail
> --
>
> Key: MNG-3470
> URL: http://jira.codehaus.org/browse/MNG-3470
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.8
>Reporter: Benjamin Bentmann
>Priority: Minor
> Attachments: mng-3470-it.patch
>
>
> If a dependency has a corrupted POM and the corresponding remote repo is
> configured with checksumPolicy=fail, Maven does still not fail the build.
> This seems to caused by the fix for MNG-2282: The original
> ChecksumFailedException is wrapped into a TransferFailedException which is
> errorneously converted into a ResourceDoesNotExistException by
> DefaultWagonManager.getArtifact(). Next up, DefaultArtifactResolver.resolve()
> wraps this into an ArtifactNotFoundException.
> DefaultMavenProjectBuilder.findModelFromRepository() will catch this and
> simply create a stub POM instead of failing.
> The code from the trunk looks different, not sure if it suffers from this.
> Now that I have a JIRA id, I will try to setup an IT.
--
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: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127820 ] Dennis Lundberg commented on MCHANGES-106: -- You didn't include the logging output. > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-results.xml, jira-results.xml, > pom.xml, screenshot-1.jpg > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127818 ] Arnaud Heritier commented on MECLIPSE-404: -- I stopped to think a long long time ago ;-) I agree with Benjamin. What you used was an hack over a bug to try to have portable settings. Why I could recommend instead of trying to have an ugly fix in the plugin is that you use 2 profiles in your settings. Those profiles are activated with the OS and define the good path for the local repository. It will be transparent for your team but it will be in the maven way. WDYT ? > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127814
]
Benjamin Bentmann commented on MECLIPSE-404:
bq. we should still be able to use forward slashes
There is nothing wrong with the slashes themselves, "C:\nemours\..." and
"C:/nemours/..." wil work equally well on Windows. The important difference is
between "C:/nemours/..." and "/nemours/...": The first path being recognized as
absolute, the later one as relative.
Up to 2.4, the plugin's {{EclipseClassPathWriter}} did not check for a relative
path when generating the ".classpath". This has been changed in
[r616816|http://svn.apache.org/viewvc?view=rev&revision=616816] to solve
MECLIPSE-344.
bq. In our organization we use a distributed settings.xml that all developers
use.
To my knowledge, the settings.xml is not meant for such a scenario. In general,
there is simply no portable way of specifying an absolute path across Win/Unix
with a simple string constant: What the one system considers absolute will the
other system consider relative.
Therefore, you might want to consider to replace the localRepository value (or
at least some prefix) with an expression, e.g.
{code:xml}
${env.M2_REPO}
{code}
This way, developers could deal with the different filesystems but still share
the rest of the settings.xml.
In the end, that's a general configuration issue... let's see what Arnaud
thinks.
> Duplicated local repository path in the generated .classpath file
> -
>
> Key: MECLIPSE-404
> URL: http://jira.codehaus.org/browse/MECLIPSE-404
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.5
>Reporter: Baptiste MATHUS
>
> The generated .classpath is not correct.
> This problem seems to be related to using a non default repository location.
> In fact, if localRepository (in settings.xml) is the following:
> /path/to/repository
> Then all classpathentries in the .classpath file are generated as in the
> following example:
> M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> instead of
> M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> I can create a dedicated testcase project if necessary (if you have problem
> reproducing this issue) but I think this will be easy to reproduce by just
> testing with a non default repository location.
> Thanks a lot.
> Cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127806 ] whoover edited comment on MECLIPSE-404 at 3/18/08 1:43 PM: --- In our organization we use a distributed settings.xml that all developers use. Therefore, It still makes sense to have universal paths in settings.xml :o) I found that if I specify C:\nemours\java\maven\repository it does solve the issue, but imho, we should still be able to use forward slashes as possible prior to 2.5 I have seen that a lot of people in the forum are having the same issue. was (Author: whoover): In our organization we use a distributed settings.xml that all developers use. Therefore, It still makes sense to have universal paths in settings.xml :o) I found that if I specify C:\nemours\java\maven\repository it does solve the issue, but imho, we should still be able to use forward slashes as possible prior to 2.4 I have seen that a lot of people in the forum are having the same issue. > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127806 ] Will Hoover commented on MECLIPSE-404: -- In our organization we use a distributed settings.xml that all developers use. Therefore, It still makes sense to have universal paths in settings.xml :o) I found that if I specify C:\nemours\java\maven\repository it does solve the issue, but imho, we should still be able to use forward slashes as possible prior to 2.4 I have seen that a lot of people in the forum are having the same issue. > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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-3470) Build does not fail on corrupted POM even with checksumPolicy=fail
[ http://jira.codehaus.org/browse/MNG-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3470: --- Description: If a dependency has a corrupted POM and the corresponding remote repo is configured with checksumPolicy=fail, Maven does still not fail the build. This seems to caused by the fix for MNG-2282: The original ChecksumFailedException is wrapped into a TransferFailedException which is errorneously converted into a ResourceDoesNotExistException by DefaultWagonManager.getArtifact(). Next up, DefaultArtifactResolver.resolve() wraps this into an ArtifactNotFoundException. DefaultMavenProjectBuilder.findModelFromRepository() will catch this and simply create a stub POM instead of failing. The code from the trunk looks different, not sure if it suffers from this. Now that I have a JIRA id, I will try to setup an IT. Summary: Build does not fail on corrupted POM even with checksumPolicy=fail (was: Build does not fail on corrp) > Build does not fail on corrupted POM even with checksumPolicy=fail > -- > > Key: MNG-3470 > URL: http://jira.codehaus.org/browse/MNG-3470 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Minor > > If a dependency has a corrupted POM and the corresponding remote repo is > configured with checksumPolicy=fail, Maven does still not fail the build. > This seems to caused by the fix for MNG-2282: The original > ChecksumFailedException is wrapped into a TransferFailedException which is > errorneously converted into a ResourceDoesNotExistException by > DefaultWagonManager.getArtifact(). Next up, DefaultArtifactResolver.resolve() > wraps this into an ArtifactNotFoundException. > DefaultMavenProjectBuilder.findModelFromRepository() will catch this and > simply create a stub POM instead of failing. > The code from the trunk looks different, not sure if it suffers from this. > Now that I have a JIRA id, I will try to setup an IT. -- 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-3470) Build does not fail on corrp
Build does not fail on corrp Key: MNG-3470 URL: http://jira.codehaus.org/browse/MNG-3470 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Benjamin Bentmann Priority: Minor -- 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-2282) If a repo is down, maven stops the buid instead of trying other repos
[ http://jira.codehaus.org/browse/MNG-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-2282: --- Fix Version/s: (was: 2.1-alpha-1) 2.0.5 Merged to 2.0.x branch in r406684, next Maven release was in r495436 and this was 2.0.5 > If a repo is down, maven stops the buid instead of trying other repos > - > > Key: MNG-2282 > URL: http://jira.codehaus.org/browse/MNG-2282 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Guillaume Nodet >Assignee: Kenney Westerhof >Priority: Blocker > Fix For: 2.0.5 > > > In this case, the artifact is available at > http://www.ibiblio.org/maven2/activemq/jmdns/1.0-RC2/ and the build always > fail until the artifact is downloaded manually. > See the following build output: > + Error stacktraces are turned on. > Maven version: 2.0.4 > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settings\gnodet\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\java-bin\maven-2.0.4\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Searching for parent-POM: > org.apache.servicemix:servicemix::3.0-SNAPSHOT of project: > null:servicemix-core:jar:null in relative path: ../pom.xml > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project: null:servicemix-core:jar:null > [DEBUG] Searching for parent-POM: org.apache:apache::1 of project: > org.apache.servicemix:servicemix:pom:3.0-SNAPSHOT in relative path: ../pom.xml > [DEBUG] Parent-POM: org.apache:apache::1 not found in relative path: > ../pom.xml > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.servicemix:servicemix:pom:3.0-SNAPSHOT from the repository. > [INFO] > > [INFO] Building ServiceMix :: Core > [INFO]task-segment: [install] > [INFO] > > [DEBUG] Skipping disabled repository apache.snapshots > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Retrieving parent-POM: > org.apache.maven.plugins:maven-plugin-parent::2.0 for project: > null:maven-resources-plugin:maven-plugin:2.1 from the repository. > [DEBUG] Skipping disabled repository apache.snapshots > [DEBUG] maven-compiler-plugin: resolved to version 2.0.1 from repository > central > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for > project: null:maven-compiler-plugin:maven-plugin:2.0.1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: > org.apache.maven.plugins:maven-plugins:pom:1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.maven:maven-parent:pom:1 from the repository. > [DEBUG] Skipping disabled repository apache.snapshots > [DEBUG] maven-surefire-plugin: resolved to version 2.1.3 from repository > central > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for > project: null:maven-surefire-plugin:maven-plugin:2.1.3 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: > org.apache.maven.plugins:maven-plugins:pom:1 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.maven:maven-parent:pom:1 from the repository. > [DEBUG] Skipping disabled repository apache.snapshots > [DEBUG] maven-jar-plugin: resolved to version 2.0 from repository central > [DEBUG] Retrieving parent-POM: > org.apache.maven.plugins:maven-plugin-parent::2.0 for project: > null:maven-jar-plugin:maven-plugin:2.0 from the repository. > [DEBUG] Skipping disabled repository apache.snapshots > [DEBUG] maven-install-plugin: resolved to version 2.1 from repository central > [DEBUG] Retrieving parent-POM: > org.apache.maven.plugins:maven-plugin-parent::2.0 for project: > null:maven-install-plugin:maven-plugin:2.1 from the repository. > [DEBUG] Retrieving parent-POM: > org.apache.maven.plugins:maven-plugin-parent::2.0.1 for project: > null:maven-one-plugin:maven-plugin:1.0 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.xbean:xbean::2.3 for project: > null:maven-xbean-plugin:maven-plugin:2.3 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: > org.apache.xbean:xbean:pom:2.3 from the repository. > [DEBUG] org.apache.xbean:maven-xbean-plugin:maven-plugin:2.3:runtime > (selected for runtime) > [DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0 for project: > null:maven-archiver:jar:2.0 fro
[jira] Commented: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127795 ] Benjamin Bentmann commented on MECLIPSE-404: bq. for portability purposes. Do you copy this one settings.xml around between different machines? Usually, this file is just yours and hence portability shouldn't matter. Anyway, I still could not figure out what you expect the string "/nemours/java/maven/repository" to resolve to. Is this meant to be relative to your home directory/drive, maven home ...? I mean, what would the final absolute path look like? Will it work if you specify this final string directly in the settings.xml? > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127792 ] Will Hoover commented on MECLIPSE-404: -- I used Unix style paths as well as negating drive names for portability purposes. The paths were getting translated correctly prior to the use of version 2.5 so I'm not sure what has happened since then? > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127786
]
Benjamin Bentmann commented on MECLIPSE-404:
bq. /nemours/java/maven/repository
Forgive my dumb question, but what kind of filesytem is this? I mean until now,
I only knew absolute Win32 pathes as "C:\..." or "\\server\..." Or was this
path meant to be relative to another directory?
On Windows
new File("/nemours/java/maven/repository").isAbsolute()
is {{false}}. That might cause the troubles...
> Duplicated local repository path in the generated .classpath file
> -
>
> Key: MECLIPSE-404
> URL: http://jira.codehaus.org/browse/MECLIPSE-404
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.5
>Reporter: Baptiste MATHUS
>
> The generated .classpath is not correct.
> This problem seems to be related to using a non default repository location.
> In fact, if localRepository (in settings.xml) is the following:
> /path/to/repository
> Then all classpathentries in the .classpath file are generated as in the
> following example:
> M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> instead of
> M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> I can create a dedicated testcase project if necessary (if you have problem
> reproducing this issue) but I think this will be easy to reproduce by just
> testing with a non default repository location.
> Thanks a lot.
> Cheers.
--
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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127784 ] Will Hoover commented on MECLIPSE-404: -- sure... /nemours/java/maven/repository > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[
http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127783
]
Benjamin Bentmann commented on MECLIPSE-404:
I'm using Maven 2.0.8 with Java 1.6.0_04 on WinXP and a custom location for the
local repo ("U:\Net\Maven-2") but couldn't reproduce this yet...
bq. /path/to/repo
Will, could you please mention your actual path? Maybe there's something about
its details (spaces, UNC, ...).
> Duplicated local repository path in the generated .classpath file
> -
>
> Key: MECLIPSE-404
> URL: http://jira.codehaus.org/browse/MECLIPSE-404
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.5
>Reporter: Baptiste MATHUS
>
> The generated .classpath is not correct.
> This problem seems to be related to using a non default repository location.
> In fact, if localRepository (in settings.xml) is the following:
> /path/to/repository
> Then all classpathentries in the .classpath file are generated as in the
> following example:
> M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> instead of
> M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
> I can create a dedicated testcase project if necessary (if you have problem
> reproducing this issue) but I think this will be easy to reproduce by just
> testing with a non default repository location.
> Thanks a lot.
> Cheers.
--
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: (MAVENUPLOAD-1972) please upload GWT 1.4.62
please upload GWT 1.4.62 Key: MAVENUPLOAD-1972 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1972 Project: maven-upload-requests Issue Type: Wish Reporter: nicolas de loof Google guys just released GWT 1.4.62 (http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/bd5cbb7a0d5b60aa/b85b6c2157aa26cb) I'd like to update the codehaus GWT plugin to use this version The bundle contains server and runtime jars + development jars for windows, linux, mac and macOS leopard -- 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: (MNGSITE-41) Avoid references to the deprecated expression "${project.build.resources}"
[
http://jira.codehaus.org/browse/MNGSITE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-3453 to MNGSITE-41:
---
Fix Version/s: (was: 2.0.9)
Component/s: (was: Documentation: General)
Key: MNGSITE-41 (was: MNG-3453)
Project: Maven Project Web Site (was: Maven 2)
> Avoid references to the deprecated expression "${project.build.resources}"
> --
>
> Key: MNGSITE-41
> URL: http://jira.codehaus.org/browse/MNGSITE-41
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Trivial
> Attachments: project-resources-expression.patch
>
>
> The [Mojo API
> Spec|http://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations]
> contains a reference to the expression "${project.build.resources}" which
> has been deprecated as of MNG-715. The docs should be updated to use the
> recommended expression "${project.resources}".
--
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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127780 ] Baptiste MATHUS commented on MECLIPSE-404: -- > I just re-tested and I can't reproduce it Arf, mince alors :-). OK, I'll try creating a testcase project to show it. > What is your environment ? Java 1.5.0, OS: WinXP, maven 2.0.8 Cheers. > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127779 ] whoover edited comment on MECLIPSE-404 at 3/18/08 11:34 AM: I have the same issue when using maven-eclipse-plugin 2.5 (maven v2.0.8, Java 1.6.0_03, Windows XP) For example: mvn eclipse:clean eclipse:eclipse ... /path/to/repo ... 2.5 produces: M2_REPO/path/to/repo/commons-collections/commons-collections/3.2/commons-collections-3.2.jar 2.4 produces: M2_REPO/commons-collections/commons-collections/3.2/commons-collections-3.2.jar was (Author: whoover): I have the same issue when using maven-eclipse-plugin 2.5 (maven v2.0.8, Windows XP) For example: mvn eclipse:clean eclipse:eclipse ... /path/to/repo ... 2.5 produces: M2_REPO/path/to/repo/commons-collections/commons-collections/3.2/commons-collections-3.2.jar 2.4 produces: M2_REPO/commons-collections/commons-collections/3.2/commons-collections-3.2.jar > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127779 ] Will Hoover commented on MECLIPSE-404: -- I have the same issue when using maven-eclipse-plugin 2.5 (maven v2.0.8, Windows XP) For example: mvn eclipse:clean eclipse:eclipse ... /path/to/repo ... 2.5 produces: M2_REPO/path/to/repo/commons-collections/commons-collections/3.2/commons-collections-3.2.jar 2.4 produces: M2_REPO/commons-collections/commons-collections/3.2/commons-collections-3.2.jar > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MNGSITE-40) The documentation refers to system property "user.dir" when it should refer to "user.home"
[
http://jira.codehaus.org/browse/MNGSITE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-2956 to MNGSITE-40:
---
Affects Version/s: (was: 2.0.5)
Fix Version/s: (was: 2.0.9)
Component/s: (was: Settings)
Key: MNGSITE-40 (was: MNG-2956)
Project: Maven Project Web Site (was: Maven 2)
> The documentation refers to system property "user.dir" when it should refer
> to "user.home"
> --
>
> Key: MNGSITE-40
> URL: http://jira.codehaus.org/browse/MNGSITE-40
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment: Windows XP Professional
>Reporter: Donley R. P'Simer
>Assignee: Benjamin Bentmann
> Attachments: user-home.patch
>
>
> In several places the documentation for maven2 refers to the local repository
> and user settings.xml file being relative to the "${user.dir}" system
> property. Behavior suggests that it is actually the "${user.home}" system
> property that is being used. From the javadoc for System.getProperties() in
> jdk1.5:
> user.home User's home directory
> user.dir User's current working directory
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#getProperties()
--
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: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Boers updated MCHANGES-106: Attachment: screenshot-1.jpg This is the result when the link in the jira-reports is entered in the browser. The result is the expected list of closed issues. > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-results.xml, jira-results.xml, > pom.xml, screenshot-1.jpg > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- 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: (MCHANGES-106) the generated jira-result.xml contains no jira-items
[ http://jira.codehaus.org/browse/MCHANGES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Boers updated MCHANGES-106: Attachment: jira-report.html the empty generated report > the generated jira-result.xml contains no jira-items > > > Key: MCHANGES-106 > URL: http://jira.codehaus.org/browse/MCHANGES-106 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0-beta-3 > Environment: windows maven-2.0.8 jira Professional Edition, Version: > 3.11-#288 >Reporter: Rene Boers >Priority: Critical > Attachments: jira-report.html, jira-results.xml, jira-results.xml, > pom.xml > > > when i run the maven site or mvn changes:jira-report the resulting > jira-reports doesnot contain jira-issues it only contains the link to the > searchrequest. > This results in an empty jira-report. > I have included the jira-reports.xml and the logging from the mvn > changes:jira report. > When open the jira-reports.xml in firefox i do have a page with the request > jira-issues available. In explorer i just get the representation of the xml > file. > Any suggestions why no jira-report is generated. -- 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: (MCHANGES-106) the generated jira-result.xml contains no jira-items
the generated jira-result.xml contains no jira-items Key: MCHANGES-106 URL: http://jira.codehaus.org/browse/MCHANGES-106 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.0-beta-3 Environment: windows maven-2.0.8 jira Professional Edition, Version: 3.11-#288 Reporter: Rene Boers Priority: Critical Attachments: jira-results.xml, jira-results.xml, pom.xml when i run the maven site or mvn changes:jira-report the resulting jira-reports doesnot contain jira-issues it only contains the link to the searchrequest. This results in an empty jira-report. I have included the jira-reports.xml and the logging from the mvn changes:jira report. When open the jira-reports.xml in firefox i do have a page with the request jira-issues available. In explorer i just get the representation of the xml file. Any suggestions why no jira-report is generated. -- 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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127770 ] Arnaud Heritier commented on MECLIPSE-404: -- I just re-tested and I can't reproduce it :-( What is your environment ? OS, Java, Maven > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-403) mvn eclipse:eclipse ends on ResourceNotFoundException
[
http://jira.codehaus.org/browse/MECLIPSE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127769
]
Arnaud Heritier commented on MECLIPSE-403:
--
perhaps it was a problem because the plugin was not completely synchronized in
your mirror ...
> mvn eclipse:eclipse ends on ResourceNotFoundException
> -
>
> Key: MECLIPSE-403
> URL: http://jira.codehaus.org/browse/MECLIPSE-403
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Linux
>Reporter: Roman Pichlik
>Priority: Blocker
>
> [EMAIL PROTECTED]:~/xxx$ mvn eclipse:eclipse
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> Downloading:
> http://el4.elca-services.ch/el4j/maven2repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.pom
> WAGON_VERSION: 1.0-beta-2
> [INFO]
>
> [INFO] Building persistence-utils
> [INFO]task-segment: [eclipse:eclipse]
> [INFO]
>
> [INFO] Preparing eclipse:eclipse
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 45203 at timestamp: 1205833791902
> -
> this realm =
> app0.child-container[org.apache.maven.plugins:maven-eclipse-plugin]
> urls[0] =
> file:/home/dagi/.m2/repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.jar
> urls[1] =
> file:/home/dagi/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> this realm = plexus.core
> urls[0] = file:/usr/local/tools/maven-2.0.8/lib/maven-2.0.8-uber.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> -
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse': Unable to find
> the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse' in the
> plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
> org/codehaus/plexus/resource/loader/ResourceNotFoundException
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Tue Mar 18 10:49:52 CET 2008
> [INFO] Final Memory: 9M/79M
> [INFO]
>
--
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: (MECLIPSE-403) mvn eclipse:eclipse ends on ResourceNotFoundException
[
http://jira.codehaus.org/browse/MECLIPSE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Pichlik closed MECLIPSE-403.
--
Resolution: Cannot Reproduce
I cannot reproduce it. It might be cause by inconsistent version of the plugin
in repository. It seems that it works now when the artifact comes from repo1.
> mvn eclipse:eclipse ends on ResourceNotFoundException
> -
>
> Key: MECLIPSE-403
> URL: http://jira.codehaus.org/browse/MECLIPSE-403
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Linux
>Reporter: Roman Pichlik
>Priority: Blocker
>
> [EMAIL PROTECTED]:~/xxx$ mvn eclipse:eclipse
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> Downloading:
> http://el4.elca-services.ch/el4j/maven2repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.pom
> WAGON_VERSION: 1.0-beta-2
> [INFO]
>
> [INFO] Building persistence-utils
> [INFO]task-segment: [eclipse:eclipse]
> [INFO]
>
> [INFO] Preparing eclipse:eclipse
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 45203 at timestamp: 1205833791902
> -
> this realm =
> app0.child-container[org.apache.maven.plugins:maven-eclipse-plugin]
> urls[0] =
> file:/home/dagi/.m2/repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.jar
> urls[1] =
> file:/home/dagi/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> this realm = plexus.core
> urls[0] = file:/usr/local/tools/maven-2.0.8/lib/maven-2.0.8-uber.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> -
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse': Unable to find
> the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse' in the
> plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
> org/codehaus/plexus/resource/loader/ResourceNotFoundException
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Tue Mar 18 10:49:52 CET 2008
> [INFO] Final Memory: 9M/79M
> [INFO]
>
--
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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127767 ] Baptiste MATHUS commented on MECLIPSE-404: -- Obviously, you'll replace "/projet/MIPIH/repository" by "/path/to/repository" in the text above. Cheers. > Duplicated local repository path in the generated .classpath file > - > > Key: MECLIPSE-404 > URL: http://jira.codehaus.org/browse/MECLIPSE-404 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.5 >Reporter: Baptiste MATHUS > > The generated .classpath is not correct. > This problem seems to be related to using a non default repository location. > In fact, if localRepository (in settings.xml) is the following: > /path/to/repository > Then all classpathentries in the .classpath file are generated as in the > following example: > M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > instead of > M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar > I can create a dedicated testcase project if necessary (if you have problem > reproducing this issue) but I think this will be easy to reproduce by just > testing with a non default repository location. > Thanks a lot. > Cheers. -- 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: (MECLIPSE-403) mvn eclipse:eclipse ends on ResourceNotFoundException
[
http://jira.codehaus.org/browse/MECLIPSE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127764
]
Roman Pichlik commented on MECLIPSE-403:
Strange, it seems that works now. I've only re-run command. There is one
difference in the previous and the current log, currently the plugin artifact
comes from repo1.maven.org (see below).
[EMAIL PROTECTED]:xxxt$ mvn eclipse:eclipse
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'eclipse'.
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-
pom
6K downloaded
[INFO]
[INFO] Building xxx Maven Webapp
[INFO]task-segment: [eclipse:eclipse]
[INFO]
[INFO] Preparing eclipse:eclipse
[INFO] No goals needed for project - skipping
Downloading:
http://repo1.maven.org/maven2/org/eclipse/core/resources/3.3.0-v20070604/resources-3.3.0-v20070604.po
1K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-a
-4.pom
762b downloaded
Downloading:
http://repo1.maven.org/maven2/org/eclipse/core/resources/3.3.0-v20070604/resources-3.3.0-v20070604.ja
662K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-resources/1.0-alpha-4/plexus-resources-1.0-a
-4.jar
16K downloaded
> mvn eclipse:eclipse ends on ResourceNotFoundException
> -
>
> Key: MECLIPSE-403
> URL: http://jira.codehaus.org/browse/MECLIPSE-403
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Linux
>Reporter: Roman Pichlik
>Priority: Blocker
>
> [EMAIL PROTECTED]:~/xxx$ mvn eclipse:eclipse
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> Downloading:
> http://el4.elca-services.ch/el4j/maven2repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.pom
> WAGON_VERSION: 1.0-beta-2
> [INFO]
>
> [INFO] Building persistence-utils
> [INFO]task-segment: [eclipse:eclipse]
> [INFO]
>
> [INFO] Preparing eclipse:eclipse
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 45203 at timestamp: 1205833791902
> -
> this realm =
> app0.child-container[org.apache.maven.plugins:maven-eclipse-plugin]
> urls[0] =
> file:/home/dagi/.m2/repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.jar
> urls[1] =
> file:/home/dagi/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> this realm = plexus.core
> urls[0] = file:/usr/local/tools/maven-2.0.8/lib/maven-2.0.8-uber.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> -
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse': Unable to find
> the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse' in the
> plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
> org/codehaus/plexus/resource/loader/ResourceNotFoundException
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Tue Mar 18 10:49:52 CET 2008
> [INFO] Final Memory: 9M/79M
> [INFO]
>
--
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: (MECLIPSE-404) Duplicated local repository path in the generated .classpath file
Duplicated local repository path in the generated .classpath file - Key: MECLIPSE-404 URL: http://jira.codehaus.org/browse/MECLIPSE-404 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Workspace settings Affects Versions: 2.5 Reporter: Baptiste MATHUS The generated .classpath is not correct. This problem seems to be related to using a non default repository location. In fact, if localRepository (in settings.xml) is the following: /path/to/repository Then all classpathentries in the .classpath file are generated as in the following example: M2_REPO/projet/MIPIH/repository/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar instead of M2_REPO/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar I can create a dedicated testcase project if necessary (if you have problem reproducing this issue) but I think this will be easy to reproduce by just testing with a non default repository location. Thanks a lot. Cheers. -- 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-271) perform goal sometimes fails with multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127747 ] Brian Fox commented on MRELEASE-271: I think the root cause of this problem is the javadoc 2.3 started forking lifecycles. This will start a new build at each child and that particular build doesn't know about all the siblings so the dependency lookup fails. I think if you look closely at the logs, you'll see that it's the forked build failing and not the main one. Fortunately, Javadoc 2.4 is released which reverts to the 2.2 behavior and we recommend everyone update to it. Please try it and add a comment if it helps you or not. > perform goal sometimes fails with multi-module projects > --- > > Key: MRELEASE-271 > URL: http://jira.codehaus.org/browse/MRELEASE-271 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-6 > Environment: XP >Reporter: David Hoffer > Attachments: MavenReleaseFailure.zip, SuccessfulReleaseBuild.txt > > > We have a multi-module maven project that has recently started failing in the > release:perform goal. > We have just added a couple more modules but do not know if that is the cause > of the failure. It seems that the release:perform fails to compile the > source after the SCM tag and checkout. The failure says that it cannot find > a dependent jar but it is that jar that it is supposed to be building and > releasing! I updated to use the latest 2.0-beta-6 release plugin version but > this did not help. > Upon receiving feedback in the maven users group that others have seen this > behavior I followed their advise and added > clean install to my > parent pom which did fix the problem. > Why is the release goal failing now? When do I and when do I not need these > changes to my pom? I will attach pom and build logs in hopes this can be > fixed soon, let me know if you need additional information. > -Dave -- 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: (MPLUGIN-101) Allow customization of file encoding used for mojo extraction
[
http://jira.codehaus.org/browse/MPLUGIN-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MPLUGIN-101:
--
Component/s: Beanshell Plugins
Patch Submitted: [Yes]
> Allow customization of file encoding used for mojo extraction
> -
>
> Key: MPLUGIN-101
> URL: http://jira.codehaus.org/browse/MPLUGIN-101
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: API, Beanshell Plugins, Java Plugins, Plugin Plugin
>Affects Versions: 2.3
>Reporter: Benjamin Bentmann
> Attachments: source-file-encoding.patch
>
>
> Right now, the user has no chance to configure the file encoding used when
> scanning the source tree for mojos at the POM level, e.g. QDox's
> {{JavaDocBuilder}} simply uses the JVM's default encoding. For smooth and
> reproducible builds in a Non-ASCII world, the plugin needs an "encoding"
> parameter to pass around into the {{MojoScanner}} and finally into the
> various {{MojoDescriptorExtractor}}'s.
--
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: (MPLUGIN-101) Allow customization of file encoding used for mojo extraction
[
http://jira.codehaus.org/browse/MPLUGIN-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MPLUGIN-101:
--
Attachment: source-file-encoding.patch
> Allow customization of file encoding used for mojo extraction
> -
>
> Key: MPLUGIN-101
> URL: http://jira.codehaus.org/browse/MPLUGIN-101
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: API, Beanshell Plugins, Java Plugins, Plugin Plugin
>Affects Versions: 2.3
>Reporter: Benjamin Bentmann
> Attachments: source-file-encoding.patch
>
>
> Right now, the user has no chance to configure the file encoding used when
> scanning the source tree for mojos at the POM level, e.g. QDox's
> {{JavaDocBuilder}} simply uses the JVM's default encoding. For smooth and
> reproducible builds in a Non-ASCII world, the plugin needs an "encoding"
> parameter to pass around into the {{MojoScanner}} and finally into the
> various {{MojoDescriptorExtractor}}'s.
--
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: (MECLIPSE-403) mvn eclipse:eclipse ends on ResourceNotFoundException
[
http://jira.codehaus.org/browse/MECLIPSE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127741
]
Arnaud Heritier commented on MECLIPSE-403:
--
did you try to force the download with -cpu
Can you atttach a stacktrace in debug (-X)
> mvn eclipse:eclipse ends on ResourceNotFoundException
> -
>
> Key: MECLIPSE-403
> URL: http://jira.codehaus.org/browse/MECLIPSE-403
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Linux
>Reporter: Roman Pichlik
>Priority: Blocker
>
> [EMAIL PROTECTED]:~/xxx$ mvn eclipse:eclipse
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'eclipse'.
> Downloading:
> http://el4.elca-services.ch/el4j/maven2repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.pom
> WAGON_VERSION: 1.0-beta-2
> [INFO]
>
> [INFO] Building persistence-utils
> [INFO]task-segment: [eclipse:eclipse]
> [INFO]
>
> [INFO] Preparing eclipse:eclipse
> [INFO] [buildnumber:create {execution: default}]
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Storing buildNumber: 45203 at timestamp: 1205833791902
> -
> this realm =
> app0.child-container[org.apache.maven.plugins:maven-eclipse-plugin]
> urls[0] =
> file:/home/dagi/.m2/repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.jar
> urls[1] =
> file:/home/dagi/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> this realm = plexus.core
> urls[0] = file:/usr/local/tools/maven-2.0.8/lib/maven-2.0.8-uber.jar
> Number of imports: 6
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> import: [EMAIL PROTECTED]
> -
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse': Unable to find
> the mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse' in the
> plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
> org/codehaus/plexus/resource/loader/ResourceNotFoundException
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Tue Mar 18 10:49:52 CET 2008
> [INFO] Final Memory: 9M/79M
> [INFO]
>
--
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: (MPIR-76) Dependencies report is incorrect
[
http://jira.codehaus.org/browse/MPIR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127738
]
Jim Christenson commented on MPIR-76:
-
Here are the dependency nodes from the pom (yes, I know there are updates...)
javax.annotation
jsr250-api
1.0
javax.xml.ws
jaxws-api
2.0
javazoom
uploadbean
1.0
org.apache.cxf
cxf-rt-transports-http
2.0.5-incubator-SNAPSHOT
org.apache.poi
poi
3.0-FINAL
org.hibernate
hibernate
3.2.0.ga
org.apache.geronimo.specs
geronimo-ws-metadata_2.0_spec
1.1.2
javax.servlet
servlet-api
2.3
commons-logging
commons-logging
1.1
log4j
log4j
1.2.14
-
The dependency report from maven-project-info-reports-plugin-2.0 and 2.0.1
generate a list of compile dependencies that does not include
geronimo-ws-metadata_2.0_spec, servlet-api, commons-loggin and log4j even
though they are listed as project dependencies. However, these are listed in
the transitive dependencies.
Further, the Dependency Tree should contain all of the project dependencies as
well as the transitive dependencies -- it doesn't match as it is missing
several of the transitive dependencies.
I have tried a number of things to resolve this, but can't seem to get the
answer.
> Dependencies report is incorrect
>
>
> Key: MPIR-76
> URL: http://jira.codehaus.org/browse/MPIR-76
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Maven 2.0.7, SUN JVM 1.5.0_12, Windows XP
>Reporter: Duncan Doyle
>
> When generating a site from the following POM, the Dependencies report is
> incorrect.
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> test
> Test
> jar
> 0.0.1-SNAPSHOT
> Test
> Test Dependency Graphs
>
>
> commons-logging
> commons-logging
> 1.1
> compile
>
>
>
> javax.servlet
> servlet-api
> 2.4
> compile
>
>
>
>
> TestDependencyGraph
> file://${site.distribution.directory}/TestDependencyGraph
>
>
>
> {code}
> The Dependencies report of this project's generated site doesn't show the
> javax.servlet:servlet-api 2.4 as a compile dependency. Instead it shows it as
> a transitivie dependency. My guess is that it finds the servlet-api 2.3
> transitive dependency of commons-logging. However, the strange thing is that
> it does show the 2.4 version number in the report.
> The Dependency Graph has the same error, it shows the servlet-api as a
> transitive dependency of commons-logging instead of a compile dependency of
> my own project.
--
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: (MPLUGIN-100) Allow customization of file encoding used for generated help goal
[
http://jira.codehaus.org/browse/MPLUGIN-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MPLUGIN-100:
--
Attachment: help-goal-encoding.patch
Moved mojo parameter "encoding" up to {{AbstractGeneratorMojo}} for re-usage by
mojo scanner with regard to MPLUGIN-101.
> Allow customization of file encoding used for generated help goal
> -
>
> Key: MPLUGIN-100
> URL: http://jira.codehaus.org/browse/MPLUGIN-100
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: API, Plugin Plugin
>Affects Versions: 2.4
>Reporter: Benjamin Bentmann
> Attachments: help-goal-encoding.patch, help-goal-encoding.patch
>
>
> If the executing JVM runs using {{file.encoding}} = ISO-8859-1 but the
> project source code is expected to be encoded in UTF-8, the generated help
> goal will mess up non-ascii characters. To smoothly integrate into the build,
> the mojo needs a parameter to configure the desired encoding.
--
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: (MECLIPSE-168) make repository variable configurable (M2_REPO)
[ http://jira.codehaus.org/browse/MECLIPSE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127733 ] Marcin Kuthan commented on MECLIPSE-168: I'm also looking for this functionality. Now I have to change the M2_REPO classpath variable every time when I started working with project which uses non-default repository, or modify the .project file by hand after mvn eclipse:eclipse run. > make repository variable configurable (M2_REPO) > --- > > Key: MECLIPSE-168 > URL: http://jira.codehaus.org/browse/MECLIPSE-168 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Dan Allen >Priority: Minor > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > It would be nice to allow the name of the M2_REPO variable to be configurable > via the plugin configuration. It is possible that a user will have multiple > maven repository locations and thus it is necessary to have different eclipse > variables that point to them. > An example use case would be a developer who maintains a local repository for > access to public mirrors for personal development, while at the same time has > a local repository for a company's internal mirror for corporate development. > i.e. > M2_REPO_PERSONAL -- 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: (MAVENUPLOAD-1971) Please sync com.capgemini.platina groupId with central
Please sync com.capgemini.platina groupId with central -- Key: MAVENUPLOAD-1971 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1971 Project: maven-upload-requests Issue Type: Wish Reporter: nicolas de loof Attachments: platina.sh I've created for my company (capgemini) some maven components and corporate POM. They're distributed under apache license, so I'd like them to get deployed on central. -- 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: (MASSEMBLY-291) attach the resulting assembly not working as expected
[
http://jira.codehaus.org/browse/MASSEMBLY-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Spilker updated MASSEMBLY-291:
-
Attachment: test.zip
I stripped down my project to create a test case. It consists of two module
where moduleB depends on moduleA. ModuleA is of type "pom" and creates a zip
artifact which should be installed a the modules primary artifact. ModuleB
should use this artifact to product an archive which contains additional files.
When using 2.2-beta-1 everything is fine:
{noformat}
C:\dspilker\test>mvn clean install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - com.coremedia:test:pom:1-SNAPSHOT
[INFO] Unnamed - com.coremedia.test:moduleA:pom:1-SNAPSHOT
[INFO] Unnamed - com.coremedia.test:moduleB:pom:1-SNAPSHOT
[INFO]
[INFO] Building Unnamed - com.coremedia:test:pom:1-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing C:\dspilker\test\pom.xml to
C:\Users\dspilker.QUASIMODO\.m2\repository\com\coremedia\test\1-SNAPSHOT\t
est-1-SNAPSHOT.pom
[INFO]
[INFO] Building Unnamed - com.coremedia.test:moduleA:pom:1-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory C:\dspilker\test\moduleA\target
[INFO] [site:attach-descriptor]
[INFO] [assembly:attached {execution: make-assembly}]
[INFO] Reading assembly descriptor:
C:\dspilker\test\moduleA\src\main\assembly\zip.xml
[INFO] Building zip: C:\dspilker\test\moduleA\target\moduleA-1-SNAPSHOT.zip
[INFO] [install:install]
[INFO] Installing C:\dspilker\test\moduleA\pom.xml to
C:\Users\dspilker.QUASIMODO\.m2\repository\com\coremedia\test\modu
leA\1-SNAPSHOT\moduleA-1-SNAPSHOT.pom
[INFO] Installing C:\dspilker\test\moduleA\target\moduleA-1-SNAPSHOT.zip to
C:\Users\dspilker.QUASIMODO\.m2\repository\c
om\coremedia\test\moduleA\1-SNAPSHOT\moduleA-1-SNAPSHOT.zip
[INFO]
[INFO] Building Unnamed - com.coremedia.test:moduleB:pom:1-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory C:\dspilker\test\moduleB\target
[INFO] [site:attach-descriptor]
[INFO] [assembly:attached {execution: make-assembly}]
[INFO] Reading assembly descriptor:
C:\dspilker\test\moduleB\src\main\assembly\zip.xml
[INFO] Processing DependencySet (output=/)
[INFO] Expanding: C:\dspilker\test\moduleA\target\moduleA-1-SNAPSHOT.zip into
C:\Users\DSPILK~1.QUA\AppData\Local\Temp\a
rchived-file-set.18360180.tmp
[INFO] Building zip: C:\dspilker\test\moduleB\target\moduleB-1-SNAPSHOT.zip
[INFO] [install:install]
[INFO] Installing C:\dspilker\test\moduleB\pom.xml to
C:\Users\dspilker.QUASIMODO\.m2\repository\com\coremedia\test\modu
leB\1-SNAPSHOT\moduleB-1-SNAPSHOT.pom
[INFO] Installing C:\dspilker\test\moduleB\target\moduleB-1-SNAPSHOT.zip to
C:\Users\dspilker.QUASIMODO\.m2\repository\c
om\coremedia\test\moduleB\1-SNAPSHOT\moduleB-1-SNAPSHOT.zip
[INFO]
[INFO]
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Unnamed - com.coremedia:test:pom:1-SNAPSHOT ... SUCCESS [2.054s]
[INFO] Unnamed - com.coremedia.test:moduleA:pom:1-SNAPSHOT ... SUCCESS [0.771s]
[INFO] Unnamed - com.coremedia.test:moduleB:pom:1-SNAPSHOT ... SUCCESS [0.106s]
[INFO]
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Tue Mar 18 11:05:25 CET 2008
[INFO] Final Memory: 10M/18M
[INFO]
{noformat}
but with 2.2-beta-2 build fails:
{noformat}
C:\dspilker\test>mvn clean install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - com.coremedia:test:pom:1-SNAPSHOT
[INFO] Unnamed - com.coremedia.test:moduleA:pom:1-SNAPSHOT
[INFO] Unnamed - com.coremedia.test:moduleB:pom:1-SNAPSHOT
[INFO]
[INFO] Building Unnamed - com.coremedia:test:pom:1-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[jira] Commented: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127722
]
David Delbecq commented on MRELEASE-261:
Hi all,
making assumption about directory structure and the fact there is a common
ancestor is wrong too!
I have this svn structure
* http://server/project/topModule/trunk/pom.xml
* http://server/project/Module1/trunk/pom.xml
* http://server/project/Module2/trunk/pom.xml
and the developper desktop structure based on that svn:
{pre}
/home/user/dev/project/topModule (=http://server/project/topModule/trunk/)
+ pom.xml
+ Module1 (=http://server/project/Module1/trunk/)
+ pom.xml
+ Module2 (=http://server/project/Module2/trunk/)
+ pom.xml
{/pre}
I expect release plugin to read the submodules pom files, and especially the
entries in that poms, that clearly indicate the svn path of each
submodule, which should be tagged as this (using 1.1.1 as release version):
* http://server/project/topModule/tags/1.1.1/pom.xml
* http://server/project/Module1/tags/1.1.1/pom.xml
* http://server/project/Module2/tags/1.1.1/pom.xml
currently, only the first tag is generated, not the submodules tags.
The idea is that, during release, if plugin encounter a submodule which as a
which is different than that of parent, it should also tag it.
> release:prepare shouls support flat directory multimodule projects
> --
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Environment: linux / maven2 / svn
>Reporter: [EMAIL PROTECTED]
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
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: (MECLIPSE-403) mvn eclipse:eclipse ends on ResourceNotFoundException
mvn eclipse:eclipse ends on ResourceNotFoundException
-
Key: MECLIPSE-403
URL: http://jira.codehaus.org/browse/MECLIPSE-403
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Linux
Reporter: Roman Pichlik
Priority: Blocker
[EMAIL PROTECTED]:~/xxx$ mvn eclipse:eclipse
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'eclipse'.
Downloading:
http://el4.elca-services.ch/el4j/maven2repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.pom
WAGON_VERSION: 1.0-beta-2
[INFO]
[INFO] Building persistence-utils
[INFO]task-segment: [eclipse:eclipse]
[INFO]
[INFO] Preparing eclipse:eclipse
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 45203 at timestamp: 1205833791902
-
this realm = app0.child-container[org.apache.maven.plugins:maven-eclipse-plugin]
urls[0] =
file:/home/dagi/.m2/repository/org/apache/maven/plugins/maven-eclipse-plugin/2.5/maven-eclipse-plugin-2.5.jar
urls[1] =
file:/home/dagi/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
Number of imports: 6
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
this realm = plexus.core
urls[0] = file:/usr/local/tools/maven-2.0.8/lib/maven-2.0.8-uber.jar
Number of imports: 6
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
-
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse': Unable to find the
mojo 'org.apache.maven.plugins:maven-eclipse-plugin:2.5:eclipse' in the plugin
'org.apache.maven.plugins:maven-eclipse-plugin'
org/codehaus/plexus/resource/loader/ResourceNotFoundException
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Mar 18 10:49:52 CET 2008
[INFO] Final Memory: 9M/79M
[INFO]
--
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: (MNGSITE-39) Point out known pitfalls when developing plugins
[
http://jira.codehaus.org/browse/MNGSITE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-3273 to MNGSITE-39:
---
Component/s: (was: Documentation: Guides)
Key: MNGSITE-39 (was: MNG-3273)
Project: Maven Project Web Site (was: Maven 2)
> Point out known pitfalls when developing plugins
>
>
> Key: MNGSITE-39
> URL: http://jira.codehaus.org/browse/MNGSITE-39
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Benjamin Bentmann
>Assignee: Vincent Siveton
>Priority: Minor
> Attachments: pitfall-report-output-directory.patch,
> pitfalls-resource-bundles.patch, pitfalls-resource-bundles.patch,
> pitfalls.patch, plexus-utils.patch, plugin-api-logger.patch
>
>
> Writing a simple Maven plugin is quite easy but getting it wrong is also
> quite easy. I am just a novice but have so far noticed two subtle
> anti-patterns that plugin developers should avoid. I would expect that the
> Maven core team knows some more aspects about mojo programming that plugin
> developers should be aware of to fight bugs right from the beginning. All
> those pitfalls would fit nicely into [Plugin
> Development|http://maven.apache.org/guides/plugin/guide-java-plugin-development.html].
> Some examples: It is a bad idea to code something like
> {code:java}
> public MyMojo {
> private Log log = getLog();
> public void execute() throws MojoExecutionException {
> log.debug("...");
> }
> }
> {code}
> Getting the logger this way will retrieve some default logger instead of the
> logger that is injected into the mojo (by the plexus container?). This is
> easily noticed by the different output styles of the log messages and the
> fact that one gets [debug] message without having "-X" enabled.
> Not bad but rather dangerous is something like
> {code:java}
> public MyMojo {
> /**
> * This parameter will take a file path (file paths are
> platform-dependent...)
> * @parameter
> */
> private String outputDirectory;
> public void execute() throws MojoExecutionException {
> File outputDir = new File(outputDirectory).getAbsoluteFile();
> outputDir.mkdirs();
> }
> }
> {code}
> java.io.File resolves relative paths like "target/something" that users might
> provide in the plugin configuration against the current directory which needs
> not be the project base directory. Therefore, path parameters should be
> declared of type java.io.File rather than simple strings as Maven seems to
> automatically push in properly resolved paths into the mojo. If one really
> needs the parameter to be of type String (i.e. to try resource lookup from
> class path), the best practice to properly get an absolute path should be
> documented.
> How to get a plugin ready for reactor builds might also be worth some warning
> words. What does one need to know about aggregator-style execution, execution
> project, forking ... ?
> A further improvement might be links to recommended libraries like
> plexus-utils or plexus-components. This would point peoply to existing code
> and prevent to error-prone reinvention of the wheel (only a few things on
> earth are that simple that people get them reliably right...)
--
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: (MNGSITE-37) Document missing default lifecycle phases
[ http://jira.codehaus.org/browse/MNGSITE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNGSITE-37: - Description: Since [r233021|http://svn.apache.org/viewvc?view=rev&revision=233021] a phase "initialize" and since [r470432|http://svn.apache.org/viewvc?view=rev&revision=470432] a phase "process-test-classes" exist which are not yet documented. Component/s: (was: Documentation: Introductions) > Document missing default lifecycle phases > - > > Key: MNGSITE-37 > URL: http://jira.codehaus.org/browse/MNGSITE-37 > Project: Maven Project Web Site > Issue Type: Sub-task >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: missing-lifecycle-phases.patch > > > Since [r233021|http://svn.apache.org/viewvc?view=rev&revision=233021] a phase > "initialize" and since > [r470432|http://svn.apache.org/viewvc?view=rev&revision=470432] a phase > "process-test-classes" exist which are not yet documented. -- 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: (MNGSITE-38) Tweak lifecylce intro
[ http://jira.codehaus.org/browse/MNGSITE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNGSITE-38: - Fix Version/s: (was: Documentation Deficit) Component/s: (was: Documentation: General) > Tweak lifecylce intro > - > > Key: MNGSITE-38 > URL: http://jira.codehaus.org/browse/MNGSITE-38 > Project: Maven Project Web Site > Issue Type: Sub-task >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Attachments: lifecycle-docs.patch > > -- 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: (MNGSITE-38) Tweak lifecylce intro
[ http://jira.codehaus.org/browse/MNGSITE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-3446 to MNGSITE-38: --- Description: (was: Fixed some technical errors, typos, style.) Key: MNGSITE-38 (was: MNG-3446) Project: Maven Project Web Site (was: Maven 2) > Tweak lifecylce intro > - > > Key: MNGSITE-38 > URL: http://jira.codehaus.org/browse/MNGSITE-38 > Project: Maven Project Web Site > Issue Type: Sub-task > Components: Documentation: General >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: Documentation Deficit > > Attachments: lifecycle-docs.patch > > -- 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: (MNGSITE-36) Revise Introduction to the Build Lifecycle
[ http://jira.codehaus.org/browse/MNGSITE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-2655 to MNGSITE-36: --- Fix Version/s: (was: Documentation Deficit) Component/s: (was: Documentation: Introductions) Key: MNGSITE-36 (was: MNG-2655) Project: Maven Project Web Site (was: Maven 2) > Revise Introduction to the Build Lifecycle > -- > > Key: MNGSITE-36 > URL: http://jira.codehaus.org/browse/MNGSITE-36 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Franz Allan Valencia See >Assignee: Vincent Siveton >Priority: Minor > Attachments: MNG-2655-maven-site.patch > > > * Provide a Table of Contents (the page is too long). > * Enumerate the available lifecycles (default, clean, site). > * Provide references to the list of phases for those lifecycles lifecycles . > * Explain goals and how they relate to the build phases. > * Provide references to the default goal bindings on the build phases. > * Explain what plugins are and how they relate to goals > * Transfer the "...For developers" section to Guide to Java Plugin > Development. Users don't need to know tihs. -- 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: (MNGSITE-37) Document missing default lifecycle phases
[ http://jira.codehaus.org/browse/MNGSITE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MNG-3445 to MNGSITE-37: --- Description: (was: Since [r233021|http://svn.apache.org/viewvc?view=rev&revision=233021] a phase "initialize" and since [r470432|http://svn.apache.org/viewvc?view=rev&revision=470432] a phase "process-test-classes" exist which are not yet documented.) Key: MNGSITE-37 (was: MNG-3445) Project: Maven Project Web Site (was: Maven 2) > Document missing default lifecycle phases > - > > Key: MNGSITE-37 > URL: http://jira.codehaus.org/browse/MNGSITE-37 > Project: Maven Project Web Site > Issue Type: Sub-task > Components: Documentation: Introductions >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: missing-lifecycle-phases.patch > > -- 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
