[jira] Created: (MECLIPSE-630) New **/*.java sources inclusion fails for resources generated by phase 'generate-resources'
New **/*.java sources inclusion fails for resources generated by phase 'generate-resources' --- Key: MECLIPSE-630 URL: http://jira.codehaus.org/browse/MECLIPSE-630 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: mcbain4711 Genrated resources (1) should be handled the same as normal resources (2) and not as generated Sources. [.classpath] 1) classpathentry kind=src path=target/generated-resources including=**/*.java/ 2) classpathentry kind=src path=src/main/resources excluding=**/*.java/ -- 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-630) New **/*.java sources inclusion fails for resources generated by phase 'generate-resources'
[ http://jira.codehaus.org/browse/MECLIPSE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204187#action_204187 ] mcbain4711 commented on MECLIPSE-630: - Currently the 1) is created by eclipse:eclipse which prevents accessing the resources-files. New **/*.java sources inclusion fails for resources generated by phase 'generate-resources' --- Key: MECLIPSE-630 URL: http://jira.codehaus.org/browse/MECLIPSE-630 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: mcbain4711 Genrated resources (1) should be handled the same as normal resources (2) and not as generated Sources. [.classpath] 1) classpathentry kind=src path=target/generated-resources including=**/*.java/ 2) classpathentry kind=src path=src/main/resources excluding=**/*.java/ -- 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-630) New **/*.java sources inclusion fails for resources generated by phase 'generate-resources'
[ http://jira.codehaus.org/browse/MECLIPSE-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204187#action_204187 ] mcbain4711 edited comment on MECLIPSE-630 at 12/27/09 5:17 AM: --- Currently the 1) is created by eclipse:eclipse which prevents accessing the resources-files during eclipse-junit testing. was (Author: mcbain4711): Currently the 1) is created by eclipse:eclipse which prevents accessing the resources-files. New **/*.java sources inclusion fails for resources generated by phase 'generate-resources' --- Key: MECLIPSE-630 URL: http://jira.codehaus.org/browse/MECLIPSE-630 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: mcbain4711 Genrated resources (1) should be handled the same as normal resources (2) and not as generated Sources. [.classpath] 1) classpathentry kind=src path=target/generated-resources including=**/*.java/ 2) classpathentry kind=src path=src/main/resources excluding=**/*.java/ -- 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-4039) Allow plugins the chance to alter the project artifacts/dependencies during 'resolution phase'
[ http://jira.codehaus.org/browse/MNG-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-4039: --- Fix Version/s: (was: 3.0-alpha-6) 3.x Allow plugins the chance to alter the project artifacts/dependencies during 'resolution phase' -- Key: MNG-4039 URL: http://jira.codehaus.org/browse/MNG-4039 Project: Maven 2 3 Issue Type: New Feature Components: Dependencies, IDEs, Plugin API, Plugins and Lifecycle, POM Affects Versions: 3.0-alpha-2 Environment: n/a Reporter: Steve Ebersole Assignee: Jason van Zyl Fix For: 3.x The term 'resolution phase' was taken from an email on this subject : http://www.nabble.com/Re%3A-Programmatically-adding-dependencies-to-a-MavenProject-p21668701.html Basically, there are times when a plugin could add dependencies to the project dependency tree in an effort to alleviate the project pom developer from unnecessary ugliness. My particular use-case is very fitting imo. In trying to write a plugin for antlr's gunit functionality. gUnit is a mechanism for generating JUnit tests for testing antlr grammars; it uses an antlr grammar itself to describe the tests. Typically, a project using antlr3 is going to define a dependency on the org.antlr:antlr-runtime artifact, since that artifact contains all the classes needed to utilize antlr in the runtime as well as all that need to be exposed via transitive dependencies. However, during build-time, a project using antlr is also going to need access to the org.antlr:antlr artifact which defines all the classes needed for grammar - java-class transformations. As an anti-example, currently the antlr3 plugin handles this by defining a hard dependency to a particular version of org.antlr:antlr in its pom even if that version is a mismatch from the one used by the project. Wouldn't it be great if the plugin were allowed to be smart enough to say hey, the project to which I am attached is using org.antlr:antlr-runtime:3.1.0 so i really should be using org.antlr:antlr:3.1.0 for grammar transformation? And in the case of the antlr3 plugin it actually can do this already because it does not need to muck with any of the project classpaths in order to do this. But in the case of this gunit example, that is not the case. As I said, gunit generates JUnit test classes which should then get picked up by the normal surefire mechanism and executed. The issue is that these gunit-generated JUnit classes have dependencies on gunit classes, so gunit must be available on the test compilation classpath. Following along with the discussion above, it would be fantastic if the plugin could handle all these details for the project and prepare the classpath properly. One possibility for implementing this is a new method on org.apache.maven.plugin.Mojo. Another is a new optional mojo interface like org.apache.maven.plugin.DependencyContributingMojo -- 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-1065) SummaryPluginDescriptor doesn't expose goals prefix (id)
[ http://jira.codehaus.org/browse/MNG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1065. -- Resolution: Not A Bug SummaryPluginDescriptor doesn't expose goals prefix (id) - Key: MNG-1065 URL: http://jira.codehaus.org/browse/MNG-1065 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Reporter: Jason van Zyl Fix For: 3.x Attachments: goals.png For Goals selection dialog it be nice to display goal prefixes/id (currently goals are grupped by plugins). Currently only name (human readable) and artifactid is exposed. -- 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-1065) SummaryPluginDescriptor doesn't expose goals prefix (id)
[ http://jira.codehaus.org/browse/MNG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204192#action_204192 ] Jason van Zyl commented on MNG-1065: This is an M2Eclipse issue. SummaryPluginDescriptor doesn't expose goals prefix (id) - Key: MNG-1065 URL: http://jira.codehaus.org/browse/MNG-1065 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Reporter: Jason van Zyl Fix For: 3.x Attachments: goals.png For Goals selection dialog it be nice to display goal prefixes/id (currently goals are grupped by plugins). Currently only name (human readable) and artifactid is exposed. -- 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-1086) Use the embedder in Maven's integration tests
[ http://jira.codehaus.org/browse/MNG-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1086. -- Resolution: Fixed Fix Version/s: (was: 3.x) 3.0-alpha-6 Use the embedder in Maven's integration tests - Key: MNG-1086 URL: http://jira.codehaus.org/browse/MNG-1086 Project: Maven 2 3 Issue Type: Task Components: Integration Tests Reporter: Jason van Zyl Fix For: 3.0-alpha-6 -- 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-1067) Replace the mock plugin data with real data
[ http://jira.codehaus.org/browse/MNG-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204193#action_204193 ] Jason van Zyl commented on MNG-1067: We can already glean all information using the Nexus index. Replace the mock plugin data with real data --- Key: MNG-1067 URL: http://jira.codehaus.org/browse/MNG-1067 Project: Maven 2 3 Issue Type: Task Components: Embedding Reporter: Jason van Zyl Fix For: 3.x Initially we need to download the plugin metadata and use that to grab the metadata from a plugin JAR. Eventually we can create an index. -- 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-1067) Replace the mock plugin data with real data
[ http://jira.codehaus.org/browse/MNG-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1067. -- Resolution: Won't Fix Replace the mock plugin data with real data --- Key: MNG-1067 URL: http://jira.codehaus.org/browse/MNG-1067 Project: Maven 2 3 Issue Type: Task Components: Embedding Reporter: Jason van Zyl Fix For: 3.x Initially we need to download the plugin metadata and use that to grab the metadata from a plugin JAR. Eventually we can create an index. -- 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-1086) Use the embedder in Maven's integration tests
[ http://jira.codehaus.org/browse/MNG-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204194#action_204194 ] Jason van Zyl commented on MNG-1086: Benjamin has implemented this and is an option for running the ITs now. Use the embedder in Maven's integration tests - Key: MNG-1086 URL: http://jira.codehaus.org/browse/MNG-1086 Project: Maven 2 3 Issue Type: Task Components: Integration Tests Reporter: Jason van Zyl Fix For: 3.0-alpha-6 -- 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-1119) Allow to use custom pom resolution strategy
[ http://jira.codehaus.org/browse/MNG-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204195#action_204195 ] Jason van Zyl commented on MNG-1119: Implemented in 3.x as a specific workspace resolver interface which IDE integration can utilize. M2Eclipse is already using this interface. Allow to use custom pom resolution strategy --- Key: MNG-1119 URL: http://jira.codehaus.org/browse/MNG-1119 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Reporter: Eugene Kuleshov Fix For: 3.x Currently all dependencies come from MavenEmbedder.readProjectWithDependencies() method that is using passed pom.xml to resolve dependencies from m2 repositories. It is possible that some of the dependencies could exist as other Eclipse projects in the same workspace. It would be interesting to hook up Eclipse-specific pom resolver, so it would implement IDE-specific logic to check if there are poms avaialble and if nothing is there use default resolution strategy. -- 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-1119) Allow to use custom pom resolution strategy
[ http://jira.codehaus.org/browse/MNG-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1119. -- Resolution: Fixed Allow to use custom pom resolution strategy --- Key: MNG-1119 URL: http://jira.codehaus.org/browse/MNG-1119 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Reporter: Eugene Kuleshov Fix For: 3.x Currently all dependencies come from MavenEmbedder.readProjectWithDependencies() method that is using passed pom.xml to resolve dependencies from m2 repositories. It is possible that some of the dependencies could exist as other Eclipse projects in the same workspace. It would be interesting to hook up Eclipse-specific pom resolver, so it would implement IDE-specific logic to check if there are poms avaialble and if nothing is there use default resolution strategy. -- 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-1140) document how other common directory layouts could be used within/migrated to m2
[ http://jira.codehaus.org/browse/MNG-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1140. -- Resolution: Fixed document how other common directory layouts could be used within/migrated to m2 --- Key: MNG-1140 URL: http://jira.codehaus.org/browse/MNG-1140 Project: Maven 2 3 Issue Type: Task Components: Documentation: General Reporter: Brett Porter Priority: Minor Fix For: Documentation Deficit -- 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-1140) document how other common directory layouts could be used within/migrated to m2
[ http://jira.codehaus.org/browse/MNG-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204196#action_204196 ] Jason van Zyl commented on MNG-1140: This is handled well enough in the books available. document how other common directory layouts could be used within/migrated to m2 --- Key: MNG-1140 URL: http://jira.codehaus.org/browse/MNG-1140 Project: Maven 2 3 Issue Type: Task Components: Documentation: General Reporter: Brett Porter Priority: Minor Fix For: Documentation Deficit -- 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-1175) Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log
[ http://jira.codehaus.org/browse/MNG-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1175. -- Resolution: Fixed Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log --- Key: MNG-1175 URL: http://jira.codehaus.org/browse/MNG-1175 Project: Maven 2 3 Issue Type: Task Components: Embedding Reporter: Eugene Kuleshov Assignee: Jason van Zyl Priority: Critical Fix For: 3.x Maven plugins are using its own logging framework ...plugin.logging.Log which is quite the same as MavenEmbedderLogger exposed by embedder. Please investigate if plugin logger should be used directly. That could be helpful if some of IDE plugins would use maven plugins directly (e.g. some utility classes from maven-eclipse-plugin) -- 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-1175) Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log
[ http://jira.codehaus.org/browse/MNG-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204197#action_204197 ] Jason van Zyl commented on MNG-1175: There are already too many logging APIs, in the future we'll just use the SLF4J interace and inject the logger like any other component. Investigate if MavenEmbedderLogger can be replaced by ...plugin.logging.Log --- Key: MNG-1175 URL: http://jira.codehaus.org/browse/MNG-1175 Project: Maven 2 3 Issue Type: Task Components: Embedding Reporter: Eugene Kuleshov Assignee: Jason van Zyl Priority: Critical Fix For: 3.x Maven plugins are using its own logging framework ...plugin.logging.Log which is quite the same as MavenEmbedderLogger exposed by embedder. Please investigate if plugin logger should be used directly. That could be helpful if some of IDE plugins would use maven plugins directly (e.g. some utility classes from maven-eclipse-plugin) -- 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-1191) need to correctly distinguish between maven internal errors and user errors
[ http://jira.codehaus.org/browse/MNG-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1191. -- Resolution: Fixed need to correctly distinguish between maven internal errors and user errors --- Key: MNG-1191 URL: http://jira.codehaus.org/browse/MNG-1191 Project: Maven 2 3 Issue Type: Improvement Components: Errors Reporter: Brett Porter Fix For: 3.x currently don't know much about the exception that occurred and whether it should be autoreported as a crash, or if it is user error, or user environment. -- 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-1191) need to correctly distinguish between maven internal errors and user errors
[ http://jira.codehaus.org/browse/MNG-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204198#action_204198 ] Jason van Zyl commented on MNG-1191: The plumbing for this is now available in trunk. It will be an ongoing process to improve this. need to correctly distinguish between maven internal errors and user errors --- Key: MNG-1191 URL: http://jira.codehaus.org/browse/MNG-1191 Project: Maven 2 3 Issue Type: Improvement Components: Errors Reporter: Brett Porter Fix For: 3.x currently don't know much about the exception that occurred and whether it should be autoreported as a crash, or if it is user error, or user environment. -- 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-136) Allow the selection of the xml (un)marshalling tools based on the POM version.
[ http://jira.codehaus.org/browse/MNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-136. - Resolution: Fixed Allow the selection of the xml (un)marshalling tools based on the POM version. -- Key: MNG-136 URL: http://jira.codehaus.org/browse/MNG-136 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Jason van Zyl Assignee: Jason van Zyl Priority: Critical Fix For: 3.x Depending on what version of the POM we are dealing with we need to be able to deal with those various versions. We probably also have to think about how incompatible elements are dealt with. -- 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-136) Allow the selection of the xml (un)marshalling tools based on the POM version.
[ http://jira.codehaus.org/browse/MNG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204199#action_204199 ] Jason van Zyl commented on MNG-136: --- The internals of Maven now allow anything. This mechanism is being used in Polyglot Maven. Allow the selection of the xml (un)marshalling tools based on the POM version. -- Key: MNG-136 URL: http://jira.codehaus.org/browse/MNG-136 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Jason van Zyl Assignee: Jason van Zyl Priority: Critical Fix For: 3.x Depending on what version of the POM we are dealing with we need to be able to deal with those various versions. We probably also have to think about how incompatible elements are dealt with. -- 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-1439) Organization Object Model (OOM)
[ http://jira.codehaus.org/browse/MNG-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1439. -- Resolution: Won't Fix Organization Object Model (OOM) Key: MNG-1439 URL: http://jira.codehaus.org/browse/MNG-1439 Project: Maven 2 3 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 3.x Would be cool to start capturing organizational information and just use a reference from projects to the OOM. -- 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-1439) Organization Object Model (OOM)
[ http://jira.codehaus.org/browse/MNG-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204201#action_204201 ] Jason van Zyl commented on MNG-1439: Out of scope for Maven, we have enough to deal with. Organization Object Model (OOM) Key: MNG-1439 URL: http://jira.codehaus.org/browse/MNG-1439 Project: Maven 2 3 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 3.x Would be cool to start capturing organizational information and just use a reference from projects to the OOM. -- 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-1440) Developer Object Model (DOM)
[ http://jira.codehaus.org/browse/MNG-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204202#action_204202 ] Jason van Zyl commented on MNG-1440: Out of scope for Maven, we have enough to deal with. Developer Object Model (DOM) Key: MNG-1440 URL: http://jira.codehaus.org/browse/MNG-1440 Project: Maven 2 3 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 2.3.x Would be cool to be able to reference a developer by id from any POM and get their full range of information. -- 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-1440) Developer Object Model (DOM)
[ http://jira.codehaus.org/browse/MNG-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1440. -- Resolution: Won't Fix Developer Object Model (DOM) Key: MNG-1440 URL: http://jira.codehaus.org/browse/MNG-1440 Project: Maven 2 3 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 2.3.x Would be cool to be able to reference a developer by id from any POM and get their full range of information. -- 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-1592) Top level element in POM is not correctly validated
[ http://jira.codehaus.org/browse/MNG-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1592. -- Resolution: Fixed Top level element in POM is not correctly validated --- Key: MNG-1592 URL: http://jira.codehaus.org/browse/MNG-1592 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: 3.x Attachments: it1019.patch this pom doesn't make the build break modelzz modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId version1.0/version /modelzz and I'm starting to see wrong poms with a top level model instead of 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] Commented: (MNG-1592) Top level element in POM is not correctly validated
[ http://jira.codehaus.org/browse/MNG-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204205#action_204205 ] Jason van Zyl commented on MNG-1592: You get something like this now: [INFO] Scanning for projects... [ERROR] The build could not read 1 project - [Help 1] [ERROR] The project org.apache.maven:maven:3.0-SNAPSHOT (/Users/jvanzyl/js/org/apache/maven/maven-3/trunk/pom.xml) has 1 error [ERROR] Malformed POM /Users/jvanzyl/js/org/apache/maven/maven-3/trunk/pom.xml: Expected root element 'project' but found 'model' (position: START_TAG seen ...apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;... @13:203) @ (/Users/jvanzyl/js/org/apache/maven/maven-3/trunk/pom.xml) - [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/ModelParseException Top level element in POM is not correctly validated --- Key: MNG-1592 URL: http://jira.codehaus.org/browse/MNG-1592 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: 3.x Attachments: it1019.patch this pom doesn't make the build break modelzz modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdtest/artifactId version1.0/version /modelzz and I'm starting to see wrong poms with a top level model instead of 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] Commented: (MNG-1667) M2_HOME is not used in the way described in README.txt and as such bootstrap build fails
[
http://jira.codehaus.org/browse/MNG-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204206#action_204206
]
Jason van Zyl commented on MNG-1667:
Bootstraps work on the grid, the issue hasn't been looked at in a year. Reopen
if it's still an issue.
M2_HOME is not used in the way described in README.txt and as such bootstrap
build fails
Key: MNG-1667
URL: http://jira.codehaus.org/browse/MNG-1667
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build
Environment: Win32 (XP SP2)
Reporter: John Allen
Fix For: 2.2.x
From README.txt
Set the environment variable M2_HOME pointing to the dir where you want
Maven2 installed.
NOTE: presently, the directory {M2_HOME}/bin must be in your path:
set PATH=%PATH%;%M2_HOME%\bin
or
export PATH=$PATH:$M2_HOME/bin
MVN SNAPSHOT is actually installed into %M2_HOME$/../maven-2.0.1-SNAPSHOT
and this is not the location on the PATH so integration tests fail.
--
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-1667) M2_HOME is not used in the way described in README.txt and as such bootstrap build fails
[
http://jira.codehaus.org/browse/MNG-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-1667.
--
Resolution: Fixed
M2_HOME is not used in the way described in README.txt and as such bootstrap
build fails
Key: MNG-1667
URL: http://jira.codehaus.org/browse/MNG-1667
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build
Environment: Win32 (XP SP2)
Reporter: John Allen
Fix For: 2.2.x
From README.txt
Set the environment variable M2_HOME pointing to the dir where you want
Maven2 installed.
NOTE: presently, the directory {M2_HOME}/bin must be in your path:
set PATH=%PATH%;%M2_HOME%\bin
or
export PATH=$PATH:$M2_HOME/bin
MVN SNAPSHOT is actually installed into %M2_HOME$/../maven-2.0.1-SNAPSHOT
and this is not the location on the PATH so integration tests fail.
--
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-1725) Find a reusable/consistent way to insulate Mojos from 'does not implement Log' in commons-logging
[ http://jira.codehaus.org/browse/MNG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1725. -- Resolution: Fixed Find a reusable/consistent way to insulate Mojos from 'does not implement Log' in commons-logging - Key: MNG-1725 URL: http://jira.codehaus.org/browse/MNG-1725 Project: Maven 2 3 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: John Casey Fix For: 3.x I've had to add a runtime dependency on log4j to the checkstyle plugin to allow it to work, since there are classloader issues with using the Jdk14Logger provider. We will continue to have these issues until we find a way to resolve this consistently for all plugins. Possibly some sort of shared-code utility or something... -- 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-1725) Find a reusable/consistent way to insulate Mojos from 'does not implement Log' in commons-logging
[ http://jira.codehaus.org/browse/MNG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204207#action_204207 ] Jason van Zyl commented on MNG-1725: We'll fix this using SLF4J as the logging API and implementation which sequesters commons-logging. Find a reusable/consistent way to insulate Mojos from 'does not implement Log' in commons-logging - Key: MNG-1725 URL: http://jira.codehaus.org/browse/MNG-1725 Project: Maven 2 3 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: John Casey Fix For: 3.x I've had to add a runtime dependency on log4j to the checkstyle plugin to allow it to work, since there are classloader issues with using the Jdk14Logger provider. We will continue to have these issues until we find a way to resolve this consistently for all plugins. Possibly some sort of shared-code utility or something... -- 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-1203) snapshot directories create in local repository on some occasions
[ http://jira.codehaus.org/browse/MNG-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1203. -- Resolution: Cannot Reproduce snapshot directories create in local repository on some occasions - Key: MNG-1203 URL: http://jira.codehaus.org/browse/MNG-1203 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Reporter: Brett Porter Priority: Trivial Fix For: 2.2.x do you still see this? -- 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-1203) snapshot directories create in local repository on some occasions
[ http://jira.codehaus.org/browse/MNG-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204209#action_204209 ] Jason van Zyl commented on MNG-1203: Vague description, provide an IT or reopen if the problem can be reproduced. snapshot directories create in local repository on some occasions - Key: MNG-1203 URL: http://jira.codehaus.org/browse/MNG-1203 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Reporter: Brett Porter Priority: Trivial Fix For: 2.2.x do you still see this? -- 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-1569) Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare
[ http://jira.codehaus.org/browse/MNG-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1569: --- Fix Version/s: (was: 3.x) 3.1.alpha1 This will be one of the key deprecations to make during 3.0 as it will likely affect several plugins that are twiddling with what should be immutable information. Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare -- Key: MNG-1569 URL: http://jira.codehaus.org/browse/MNG-1569 Project: Maven 2 3 Issue Type: New Feature Components: Design, Patterns Best Practices Affects Versions: 2.0 Reporter: John Casey Priority: Trivial Fix For: 3.1.alpha1 We need to have the ability to look at a mojo descriptor and see how it will change the build environment. This requires two things: 1. Cut off the loophole allowing unauthorized mutation of build state by making build state read-only to the mojo 2. Provide an API/annotation-set to allow explicit export of values from a mojo, where they will be incorporated into the build state. This should enable things like determining whether a mojo generates sources, or collecting the source directories (even generated ones) by scanning the plugins configured for the build. -- 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-1867) deprecate system scope, analyse other use cases
[ http://jira.codehaus.org/browse/MNG-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1867: --- Fix Version/s: (was: 3.x) 3.1.alpha1 Deprecate during 3.0, remove in 3.1. System scope and picking artifacts up off the local file system is bad. deprecate system scope, analyse other use cases --- Key: MNG-1867 URL: http://jira.codehaus.org/browse/MNG-1867 Project: Maven 2 3 Issue Type: Task Components: Artifacts and Repositories, Design, Patterns Best Practices Reporter: Brett Porter Priority: Trivial Fix For: 3.1.alpha1 possibly can avoid all use cases for system scope through proper use of alternate resolvers. Gather use cases (see MNG-1471) to ensure. -- 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-1883) it plugin not picking up the plugin being built (goes to the local repo instead)
[ http://jira.codehaus.org/browse/MNG-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1883: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Validate this is fixed. I'm pretty sure it is. it plugin not picking up the plugin being built (goes to the local repo instead) Key: MNG-1883 URL: http://jira.codehaus.org/browse/MNG-1883 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.1 Environment: maven 2.0.1 Reporter: Vincent Massol Fix For: 3.0-alpha-7 Try the following to reproduce the problem: - checkout the clover plugin - delete the clover plugin from your local - run mvn install on the clover plugin. It'll start the it plugin and try to execute an it test that requires the clover plugin - it'll fail -- 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-1902) track attempted downloads and only re-attempt on certain intervals
[ http://jira.codehaus.org/browse/MNG-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1902: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 track attempted downloads and only re-attempt on certain intervals -- Key: MNG-1902 URL: http://jira.codehaus.org/browse/MNG-1902 Project: Maven 2 3 Issue Type: Improvement Components: Artifacts and Repositories Reporter: Brett Porter Fix For: 3.0-alpha-7 currently, because files are not stored locally when not found, files are always looked for. OTOH, we don't want to store incorrect info, especially if it is permanent (ie, not a snapshot). We should track in the local repo metadata files that were not found and when, and check again on intervals. This should be part of the resolver so the site plugin (site descriptors), poms and more all benefit. -- 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-1885) Uniquely identify modules by module name and version number
[ http://jira.codehaus.org/browse/MNG-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204213#action_204213 ] Jason van Zyl commented on MNG-1885: The recursive scanning of directories has been removed in 3.x in favor of building in the make-like reactor support. Uniquely identify modules by module name and version number --- Key: MNG-1885 URL: http://jira.codehaus.org/browse/MNG-1885 Project: Maven 2 3 Issue Type: Improvement Components: Design, Patterns Best Practices Environment: This is a platform independent issue. Windows XP, Java builds Reporter: John Reynolds Priority: Trivial Fix For: 3.x Currently when buiding project dependencies and/or performing a build via the reactor -r option it will not build projects that have the same project id. This works in most unique project scenarios, but in scenarios where you may have the directories for a project broken out by version number, you end up with the same artifact-id for the multiple projects. The only difference would be that they are target at different versions. Example Layout Project X | +--Dev (pom.xml contains artifact ProjectX version Dev (Dev head contains latest release) | +--1.0 (pom.xml contains artifact ProjectX Version 1.0 | +--2.0 (pom.xml contains artifact ProjectX Version 2.0 We may actually build multiple versions of plug-ins that could be deployed and built as a whole. It would simplify the builds if the -r option would build each project and version it finds. Today it will only build one of them. The same issue or set of problems is presented to the module concept. It's difficult for a parent project that needs to build multiple projects to point at specific versions. Today they project would require a unique artifact and a module pointing to each directory for the pom. It will only build one of the instances of the artifact ID. This forces changes to the parent pom, to deal with the issue. It would be nice to be able to build a specific version or all the versions related to a module. Multi-Project module builds should have the knowledge of versions when deciding what to build, with an option of including specific versions or all versions of an artifactId The -r reactor option should all directories to be recursed and build multiple projects of the same artifact id, regardless over version. -- 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-1916) Making it possible for plug-in to add modules to the reactor programatically
[
http://jira.codehaus.org/browse/MNG-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-1916.
--
Resolution: Won't Fix
Making it possible for plug-in to add modules to the reactor programatically
Key: MNG-1916
URL: http://jira.codehaus.org/browse/MNG-1916
Project: Maven 2 3
Issue Type: Improvement
Components: Plugin API, Reactor and workspace
Reporter: Nils Fredrik Gjerull
Fix For: 3.x
I would like to be able to specify a number of directories as plug-in
directories, automatically discover every plug-in in those directories and
include them in the reactor. As I understands it the reactor with it's
modules ({{org.apache.maven.execution.ReactorManager}}) is created in
{{org.apache.maven.DefaultMaven}}. If I understands this correctly maven
plug-ins can't add projects to the reactor programatically.
My proposition to solve this is to add a phase which will be executed after
the pom.xml is parsed, but before the information stored in
Model/MavenProject is used, and most importantly before the {{ReactorManager
is created}}. Then you can add information to the MavenProject
programatically, increasing the flexibility for plug-ins.
I am not fluent in the maven2 code base, but it seems to me that this require
quite a lot of changes to the code. As I understands it the life cycle starts
after the {{ReactorManager}} is made, and therefore after the information in
Model have started to be used.
--
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-1916) Making it possible for plug-in to add modules to the reactor programatically
[
http://jira.codehaus.org/browse/MNG-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204214#action_204214
]
Jason van Zyl commented on MNG-1916:
You can use the same code the new site plugin is using in order to create your
own plugin system for your particular domain.
Making it possible for plug-in to add modules to the reactor programatically
Key: MNG-1916
URL: http://jira.codehaus.org/browse/MNG-1916
Project: Maven 2 3
Issue Type: Improvement
Components: Plugin API, Reactor and workspace
Reporter: Nils Fredrik Gjerull
Fix For: 3.x
I would like to be able to specify a number of directories as plug-in
directories, automatically discover every plug-in in those directories and
include them in the reactor. As I understands it the reactor with it's
modules ({{org.apache.maven.execution.ReactorManager}}) is created in
{{org.apache.maven.DefaultMaven}}. If I understands this correctly maven
plug-ins can't add projects to the reactor programatically.
My proposition to solve this is to add a phase which will be executed after
the pom.xml is parsed, but before the information stored in
Model/MavenProject is used, and most importantly before the {{ReactorManager
is created}}. Then you can add information to the MavenProject
programatically, increasing the flexibility for plug-ins.
I am not fluent in the maven2 code base, but it seems to me that this require
quite a lot of changes to the code. As I understands it the life cycle starts
after the {{ReactorManager}} is made, and therefore after the information in
Model have started to be used.
--
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-193) symmetry for outputs of a plugin
[ http://jira.codehaus.org/browse/MNG-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-193: -- Fix Version/s: (was: 3.x) 3.1.alpha1 symmetry for outputs of a plugin Key: MNG-193 URL: http://jira.codehaus.org/browse/MNG-193 Project: Maven 2 3 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Brett Porter Fix For: 3.1.alpha1 We need a way to declaratively say what the outputs of a plugins are going to be. The concrete example being the Antlr plugin that generates a source root, we should know what this is going to be before executing the plugin. -- 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-2012) build with custom repository location and settings file doesn't work anymore
[ http://jira.codehaus.org/browse/MNG-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2012. -- Resolution: Won't Fix build with custom repository location and settings file doesn't work anymore Key: MNG-2012 URL: http://jira.codehaus.org/browse/MNG-2012 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build Reporter: Jerome Lacoste Priority: Minor Fix For: 3.x Attachments: m2.log And related to the MNG-1667 breakage, ./bootstrap.sh -s ~/.m2/settings-m2trunk.xml $* with settings-m2trunk.xml pointing to a different repository doesn't work at all anymore Breaks very early during the build process. Will try to get a log. -- 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-2012) build with custom repository location and settings file doesn't work anymore
[ http://jira.codehaus.org/browse/MNG-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204215#action_204215 ] Jason van Zyl commented on MNG-2012: Bootstrapping works on the grid. If you want to use a custom settings provide a patch. We don't do this on the grid so there's little value in us implementing this. build with custom repository location and settings file doesn't work anymore Key: MNG-2012 URL: http://jira.codehaus.org/browse/MNG-2012 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build Reporter: Jerome Lacoste Priority: Minor Fix For: 3.x Attachments: m2.log And related to the MNG-1667 breakage, ./bootstrap.sh -s ~/.m2/settings-m2trunk.xml $* with settings-m2trunk.xml pointing to a different repository doesn't work at all anymore Breaks very early during the build process. Will try to get a log. -- 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-2014) build extension libraries should be added to the current artifact filter used by the plugin manager
[ http://jira.codehaus.org/browse/MNG-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2014: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 build extension libraries should be added to the current artifact filter used by the plugin manager --- Key: MNG-2014 URL: http://jira.codehaus.org/browse/MNG-2014 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.2 Reporter: John Casey Fix For: 3.0-alpha-7 currently, build extensions are not added to the artifact filter that the plugin manager uses when initializing plugin containers. This means that plugins will get another copy of any class in that build extension. Build extensions go into the core container, and should therefore be excluded from plugin containers, to ensure that plugins and the core can share the classes/instances in the extension. -- 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-2116) Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data.
[ http://jira.codehaus.org/browse/MNG-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2116: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data. -- Key: MNG-2116 URL: http://jira.codehaus.org/browse/MNG-2116 Project: Maven 2 3 Issue Type: New Feature Components: General Affects Versions: 2.0.2 Reporter: John Casey Priority: Minor Fix For: 3.0-alpha-7 Currently, Maven will create a stub POM when it cannot find one on the remote repository. However, there are cases where we need to have the ability to verify that all the components of an application or some other type of build are present. Therefore, we need a strict mode for Maven, which will suppress any stubbing activities like this. -- 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-2135) multi-project build that creates it's own plugins needs bootstrapping
[ http://jira.codehaus.org/browse/MNG-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2135: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Validate this is fixed. multi-project build that creates it's own plugins needs bootstrapping - Key: MNG-2135 URL: http://jira.codehaus.org/browse/MNG-2135 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.2 Reporter: Frank Cornelis Fix For: 3.0-alpha-7 I have a multi-project build. Some of the artifacts are maven-plugins. Other artifacts depends on these plugins. For some reason the current Maven2 is not correctly doing the dependency check before building to see whether the artifacts in the multi-project build depend on other maven-plugin artifacts within the same multi-project build. For now I solved the issue by using a second parent pom to bootstrap the build. This bootstrap parent pom is creating all the plugins. Afterwards, I can use my normal parent pom to build all artifacts. It would be nice that Maven2 could do the 'bootstrap build' himself. -- 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-2151) classpath used to build a module affects compile classpath for building another module
[ http://jira.codehaus.org/browse/MNG-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2151: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 classpath used to build a module affects compile classpath for building another module -- Key: MNG-2151 URL: http://jira.codehaus.org/browse/MNG-2151 Project: Maven 2 3 Issue Type: Bug Components: General Affects Versions: 2.0.3 Reporter: Vincent Massol Fix For: 3.0-alpha-7 Here's my project layout: daytrader/ ejb/ streamer/ where streamer depends on the ejb-client produced by the ejb/ build. If I do a mvn install in daytrader/ the build works. If I do it in streamer/ it fails. After investigation the problem was that the ejb-client produced by the ejb module was excluding by default a class required to compile streamer/. The build when run at the top level should have failed when building the streamer/ module. -- 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-2171) uninstantiable expressions fail, even if not required
[
http://jira.codehaus.org/browse/MNG-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2171:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
uninstantiable expressions fail, even if not required
-
Key: MNG-2171
URL: http://jira.codehaus.org/browse/MNG-2171
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.3
Reporter: Brett Porter
Fix For: 3.0-alpha-7
I tihnk this is actually in plexus' configurator. Try these:
@parameter expression=${executedProject}
or
@parameter default-value=${executedProject}
In a mojo with no @execute tag.
The first gives:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to configure plugin parameters for:
org.codehaus.mojo:cobertura-maven-plugin:2.0-SNAPSHOT
on the command line, specify: '-DexecutedProject=VALUE'
Cause: Class 'org.apache.maven.project.MavenProject' cannot be instantiated
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports
from the plugin 'org.codehaus.mojo:cobertura-maven-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:637)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginConfigurationException: Error
configuring: org.codehaus.mojo:cobertura-maven-plugin. Reason: Unable to
parse the created DOM for plugi
n configuration
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1036)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:576)
at
org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:462)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:678)
... 18 more
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Class 'org.apache.maven.project.MavenProject' cannot be instantiated
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:121)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:88)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1030)
[jira] Updated: (MNG-2187) Improve error message when the pom is encoded in the wrong charset
[ http://jira.codehaus.org/browse/MNG-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2187: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Improve error message when the pom is encoded in the wrong charset -- Key: MNG-2187 URL: http://jira.codehaus.org/browse/MNG-2187 Project: Maven 2 3 Issue Type: Improvement Components: Errors Affects Versions: 2.0.2, 2.0.3 Reporter: Carlos Sanchez Priority: Minor Fix For: 3.0-alpha-7 Attachments: pom.xml When the pom is encoded in a charset different than the one declared in the xml header (UTF8 by default) and containing an special char (ó or something like that), under Sun's JDK there's no error but under IBM JDK it crashes with sun.io.MalformedInputException It'd be good if we could check first the encoding or capture the exception and show an error message instead. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Failed to build model from file '/home/demo/plexus-compiler/pom.xml'. Error: 'null' [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to build model from file '/home/demo/plexus-compiler/pom.xml'. Error: 'null' at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Failed to build model from file '/home/demo/plexus-compiler/pom.xml'. Error: 'null' at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1103) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:289) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:274) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 12 more Caused by: sun.io.MalformedInputException at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java(Compiled Code)) at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java(Inlined Compiled Code)) at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java(Compiled Code)) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java(Compiled Code)) at java.io.InputStreamReader.read(InputStreamReader.java:208) at java.io.Reader.read(Reader.java:113) at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212) at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1117) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1094) ... 17 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Mar 29 04:25:41 PST 2006 [INFO] Final Memory: 2M/5M [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: (MSITE-442) Add ability to exclude a report mojo from executing
[ http://jira.codehaus.org/browse/MSITE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl moved MNG-2193 to MSITE-442: -- Complexity: (was: Intermediate) Component/s: (was: Sites Reporting) Fix Version/s: (was: 3.x) Affects Version/s: (was: 2.0.3) Key: MSITE-442 (was: MNG-2193) Project: Maven 2.x Site Plugin (was: Maven 2 3) Add ability to exclude a report mojo from executing --- Key: MSITE-442 URL: http://jira.codehaus.org/browse/MSITE-442 Project: Maven 2.x Site Plugin Issue Type: Improvement Reporter: Vincent Massol Here's a use case (see also MCLOVER-19): * I'm working on the clover plugin * I have one report mojo that forks a custom lifecycle (this one instruments the source code, runs the tests and generate a report) * I'd like to have another report which simply takes an existing clover database and generate a report out of it Right now it's not possible to implement such a use case as by default all report mojos are executed. I'd need to exclude the first report mojo (the one that forks a lifecycle) from executing when the second report mojo is executing. Thanks -- 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-2222) dependency to dependency without source code fails
[ http://jira.codehaus.org/browse/MNG-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Should be fixed. Validate. dependency to dependency without source code fails -- Key: MNG- URL: http://jira.codehaus.org/browse/MNG- Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Linux apple 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04:03:26 EDT 2005 i686 i686 i386 GNU/Linux java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) Reporter: Michael Mosmann Fix For: 3.0-alpha-7 - project1 - project2 (dep project1) - project3 (dep project2) - parent pom (module project1,project2,project3) mvn compile build project1 build project2 [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date build project3 [INFO] Failed to resolve artifact. in project2 no target created --- Workaround put Noop.java into source so it will build some sources -- 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-2235) unify .m2 configuration and have a super settings
[ http://jira.codehaus.org/browse/MNG-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2235. -- Resolution: Won't Fix unify .m2 configuration and have a super settings --- Key: MNG-2235 URL: http://jira.codehaus.org/browse/MNG-2235 Project: Maven 2 3 Issue Type: Bug Components: Settings Reporter: Brett Porter Fix For: 3.x the .m2/settings.xml configuration is located in several places, and instead should be a configuration solely of the default maven settings builder to make it easily changable. Also, any defaults in the settings model should come from a super model implemented in a similar fashion to the super pom. -- 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-2235) unify .m2 configuration and have a super settings
[ http://jira.codehaus.org/browse/MNG-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204221#action_204221 ] Jason van Zyl commented on MNG-2235: Code doesn't really look the same anymore. Reopen referencing new source if desired. unify .m2 configuration and have a super settings --- Key: MNG-2235 URL: http://jira.codehaus.org/browse/MNG-2235 Project: Maven 2 3 Issue Type: Bug Components: Settings Reporter: Brett Porter Fix For: 3.x the .m2/settings.xml configuration is located in several places, and instead should be a configuration solely of the default maven settings builder to make it easily changable. Also, any defaults in the settings model should come from a super model implemented in a similar fashion to the super pom. -- 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-2274) error in depth handling of dependency tree
[ http://jira.codehaus.org/browse/MNG-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2274. -- Resolution: Cannot Reproduce error in depth handling of dependency tree -- Key: MNG-2274 URL: http://jira.codehaus.org/browse/MNG-2274 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Brett Porter Fix For: 3.x see r399960 of the assembly plugin for a pom that showed this Basically what happened was: 1) maven-archiver brought in plexus-archiver which brought in plexus-container-default (depth 2) 2) plugin-test-harness brought in a newer plexus-container-default (depth 1), scope test 3) newer one is selected, but changes in 2.0.4 means that it keeps the first node and applies the version 4) plexus-archiver (newer version) didn't bring in plexus-container-default, but previous one is disabled, along with its children we can't shift dependencies here - the setting of the version on the farthest node should be changed so that the nearest one is selected and any dependencies from the farthest one that apply (because of the stronger scope) are dragged in. -- 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-2274) error in depth handling of dependency tree
[ http://jira.codehaus.org/browse/MNG-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204222#action_204222 ] Jason van Zyl commented on MNG-2274: Provide a test project, these projects are old and too hard to manually track down. Create a sample project that expresses the problem and reopen. error in depth handling of dependency tree -- Key: MNG-2274 URL: http://jira.codehaus.org/browse/MNG-2274 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Brett Porter Fix For: 3.x see r399960 of the assembly plugin for a pom that showed this Basically what happened was: 1) maven-archiver brought in plexus-archiver which brought in plexus-container-default (depth 2) 2) plugin-test-harness brought in a newer plexus-container-default (depth 1), scope test 3) newer one is selected, but changes in 2.0.4 means that it keeps the first node and applies the version 4) plexus-archiver (newer version) didn't bring in plexus-container-default, but previous one is disabled, along with its children we can't shift dependencies here - the setting of the version on the farthest node should be changed so that the nearest one is selected and any dependencies from the farthest one that apply (because of the stronger scope) are dragged in. -- 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-2285) local repository path cannot have special characters
[ http://jira.codehaus.org/browse/MNG-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2285: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 local repository path cannot have special characters Key: MNG-2285 URL: http://jira.codehaus.org/browse/MNG-2285 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.2 Environment: Windows XP Reporter: Ravi Varanasi Priority: Minor Fix For: 3.0-alpha-7 Attachments: settings.xml When there are special characters in the localrepository path and running the command *mvn clean*.causes the exception --- java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM anager.java:295) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De faultPluginManager.java:200) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug inManager.java:165) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa ultLifecycleExecutor.java:1218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor (DefaultLifecycleExecutor.java:1430) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListBy AggregationNeeds(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:134) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) --- Attached is the settiings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2323) Locked SNAPSHOT version ignored
[
http://jira.codehaus.org/browse/MNG-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2323:
---
Affects Version/s: 3.0-alpha-7
Locked SNAPSHOT version ignored
---
Key: MNG-2323
URL: http://jira.codehaus.org/browse/MNG-2323
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4, 3.0-alpha-7
Reporter: Joerg Schaible
Priority: Critical
Fix For: 3.x
We use for our tip revision (head revision of a branch) a snapshot version in
the form of:
_major.minor-SNAPSHOT_
If we make a (maintenance) release, we create a version like:
_major.minor.revision_
We manage our dependencies in a dependencyManagement section of a super POM,
where we define always the last released version of an artifact. A dependency
of an artifact that is always declared without explicit version unless it
makes usage of an unreleased version, then the child POM will be changed from
{code:xml}
dependency
groupIdgroup/group
artifactIdartifact/artifactId
dependency
{code}
to
{code:xml}
dependency
groupIdgroup/group
artifactIdartifact/artifactId
versionmajor.minor-SNAPSHOT/version
dependency
{code}
Unfortunately this does not work, Maven still prefers the released version.
Here in the example 2.0.0 instead of 2.0.-SNAPSHOT (snippet):
{noformat}
[INFO] [eclipse:eclipse]
[DEBUG] com.elsagsolutions.projects.components:es_logging:jar:1.0-SNAPSHOT
(selected for null)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0-SNAPSHOT:test
(applying version: 2.0.0;applying scope: test)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0.0:test (selected
for test)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (applying version: 2.1_3;)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (selected for test)
{noformat}
But it gets worse. Even if we try to lock the version in the child POM, it
does not work; the locked version is happily ignored:
{code:xml}
dependency
groupIdgroup/group
artifactIdartifact/artifactId
version[major.minor-SNAPSHOT]/version
dependency
{code}
Output from the example:
{noformat}
[INFO] [eclipse:eclipse]
[DEBUG] com.elsagsolutions.projects.components:es_logging:jar:1.0-SNAPSHOT
(selected for null)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0-SNAPSHOT:test
(setting version to: 2.0-SNAPSHOT from range: [2.0-SNAPSHOT,2.0-SNAPSHOT])
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0-SNAPSHOT:test
(applying version: 2.0.0;applying scope: test)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0.0:test (selected
for test)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (applying version: 2.1_3;)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (selected for test)
{noformat}
First problem is, that 2.0.x is treated as nearer as 2.0-SNAPSHOT. This is
IMHO wrong. The algorithm should look, at which point in the version
numbering the SNAPSHOT part starts and ignore the further numbers in the
version of released artifacts. Additionally the locked version must be
honored in any case.
--
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-2296) Display what has changed since last release upon updating a plugin to a new version
[ http://jira.codehaus.org/browse/MNG-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204223#action_204223 ] Jason van Zyl commented on MNG-2296: You can use the maven-versions-plugin to see/update changes and you're going to have to specify plugin versions in Maven 3.1 anyway. Display what has changed since last release upon updating a plugin to a new version --- Key: MNG-2296 URL: http://jira.codehaus.org/browse/MNG-2296 Project: Maven 2 3 Issue Type: New Feature Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Cédric Vidal Fix For: 3.x Today, when a new version of a plugin is released, it is automatically downloaded and this is great because it keeps you up to date. For example, this morning, a new version of the WAR plugin was released on ibiblio (I had 2.0-beta-2 previously), I got the following trace: -- [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from ibiblio Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.pom 1/1K 1K downloaded Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.jar 1/21K 21/21K 21K downloaded -- The thing is I got no clue whatsoever of what has changed between versions 2.0-beta-2 and 2.0. If I want to know was has changed, I have to manually go on the maven site or in the JIRA to figure out what has changed. It would be great if the list of changes that occured between between the version which was previously locally installed and the newly installed was displayed upon update as part of the build. The trace could be: -- [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from ibiblio Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.pom 1/1K 1K downloaded Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.jar 1/21K 21/21K 21K downloaded [INFO] Changes that occured between version 2.0-beta-2 and 2.0 are: o Added blah blah. o Corrected bug blah blah. o Removed blah blah. -- This feature might depend on adding the list of changes to the POM, which might be an issue since Maven is stable now. But that might not be such a bug deal since that POM information would most likely be optional. The changes part of the POM could be structured like Maven 1 Changes plugin's changes.xml file: http://maven.apache.org/maven-1.x/plugins/changes/ releases release version=2.0 date=in CVS action dev=vmassol type=update Blah blah. /action /release release version=1.0 date=2003-06-05 description =First stable release. action dev=vmassol type=add Added blah blah. /action action dev=vmassol type=fix issue=JIRA-XXX Corrected bug blah blah. /action action dev=vmassol type=remove due-to=John Doe due-to-email=j...@doe.com Removed blah blah. /action /release /releases -- 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-2296) Display what has changed since last release upon updating a plugin to a new version
[ http://jira.codehaus.org/browse/MNG-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2296. -- Resolution: Won't Fix Display what has changed since last release upon updating a plugin to a new version --- Key: MNG-2296 URL: http://jira.codehaus.org/browse/MNG-2296 Project: Maven 2 3 Issue Type: New Feature Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Cédric Vidal Fix For: 3.x Today, when a new version of a plugin is released, it is automatically downloaded and this is great because it keeps you up to date. For example, this morning, a new version of the WAR plugin was released on ibiblio (I had 2.0-beta-2 previously), I got the following trace: -- [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from ibiblio Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.pom 1/1K 1K downloaded Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.jar 1/21K 21/21K 21K downloaded -- The thing is I got no clue whatsoever of what has changed between versions 2.0-beta-2 and 2.0. If I want to know was has changed, I have to manually go on the maven site or in the JIRA to figure out what has changed. It would be great if the list of changes that occured between between the version which was previously locally installed and the newly installed was displayed upon update as part of the build. The trace could be: -- [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from ibiblio Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.pom 1/1K 1K downloaded Downloading: http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.0/maven-war-plugin-2.0.jar 1/21K 21/21K 21K downloaded [INFO] Changes that occured between version 2.0-beta-2 and 2.0 are: o Added blah blah. o Corrected bug blah blah. o Removed blah blah. -- This feature might depend on adding the list of changes to the POM, which might be an issue since Maven is stable now. But that might not be such a bug deal since that POM information would most likely be optional. The changes part of the POM could be structured like Maven 1 Changes plugin's changes.xml file: http://maven.apache.org/maven-1.x/plugins/changes/ releases release version=2.0 date=in CVS action dev=vmassol type=update Blah blah. /action /release release version=1.0 date=2003-06-05 description =First stable release. action dev=vmassol type=add Added blah blah. /action action dev=vmassol type=fix issue=JIRA-XXX Corrected bug blah blah. /action action dev=vmassol type=remove due-to=John Doe due-to-email=j...@doe.com Removed blah blah. /action /release /releases -- 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: (MANTTASKS-171) contribution: PluginClasspathTask (renamed from PluginDependencyTask)
[ http://jira.codehaus.org/browse/MANTTASKS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl moved MNG-2329 to MANTTASKS-171: -- Complexity: (was: Intermediate) Component/s: (was: Artifacts and Repositories) Fix Version/s: (was: 3.x) Key: MANTTASKS-171 (was: MNG-2329) Project: Maven 2.x Ant Tasks (was: Maven 2 3) contribution: PluginClasspathTask (renamed from PluginDependencyTask) - Key: MANTTASKS-171 URL: http://jira.codehaus.org/browse/MANTTASKS-171 Project: Maven 2.x Ant Tasks Issue Type: New Feature Reporter: Erik Romson Attachments: maven-artifact-ant.zip I need to run ant tasks outside of maven2, because we use ant to populate databases, generate reports etc from the database. Without going into any discussions on the appropriate usage of ant, I needed to be able to get hold of the classpath for plugins. I made a task for it. Copy - paste of DependencyTask basically. -- 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-2345) mvn -fn install fails when a module could not be found
[ http://jira.codehaus.org/browse/MNG-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2345: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 mvn -fn install fails when a module could not be found -- Key: MNG-2345 URL: http://jira.codehaus.org/browse/MNG-2345 Project: Maven 2 3 Issue Type: Bug Components: Command Line, Reactor and workspace Reporter: Lars Rosenberg Priority: Minor Fix For: 3.0-alpha-7 mvn -fn install fails when you have a mother project which reference a module in its modules section and the corresponding directory does not contain a pom.xml. This should not happen when you have the fail never option turned on. G:\si\serviceinfrastructuremvn clean install | tee build.txt [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file 'G:\si\serviceinfrastructure\si-adapter-co mmon\pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file 'G:\si\serviceinfrastructure\si-adapter-common\pom.xml'. at org.apache.maven.DefaultMaven.getProjects(Lorg/apache/maven/execution /MavenExecutionRequest;Lorg/apache/maven/profiles/ProfileManager;)Ljava/util/Lis t;(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(Lorg/apache/maven/execution/M avenExecutionRequest;Lorg/apache/maven/monitor/event/EventDispatcher;)Lorg/apach e/maven/execution/ReactorManager;(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(Lorg/apache/maven/execution/Mav enExecutionRequest;)V(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main([Ljava/lang/String;Lorg/codehaus/c lassworlds/ClassWorld;)I(MavenCli.java:256) at jrockit.reflect.NativeMethodInvoker.invoke0(Ljava/lang/Object;ILjava/ lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source) at jrockit.reflect.NativeMethodInvoker.invoke(Ljava/lang/Object;[Ljava/l ang/Object;)Ljava/lang/Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object; I)Ljava/lang/Object;(Unknown Source) at org.codehaus.classworlds.Launcher.launchEnhanced([Ljava/lang/String;) V(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch([Ljava/lang/String;)V(Launch er.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode([Ljava/lang/String ;)I(Launcher.java:430) at org.codehaus.classworlds.Launcher.main([Ljava/lang/String;)V(Launcher .java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file 'G:\si\serviceinfrastructure\si-adapter-common\pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(Ljava/l ang/String;Ljava/io/File;Z)Lorg/apache/maven/model/Model;(DefaultMavenProjectBui lder.java:1274) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(Ljava/io/File;Lorg/apache/maven/artifact/repository/ArtifactRepositor y;Lorg/apache/maven/profiles/ProfileManager;Z)Lorg/apache/maven/project/MavenPro ject;(DefaultMavenProjectBuilder.java:414) at org.apache.maven.project.DefaultMavenProjectBuilder.build(Ljava/io/Fi le;Lorg/apache/maven/artifact/repository/ArtifactRepository;Lorg/apache/maven/pr ofiles/ProfileManager;)Lorg/apache/maven/project/MavenProject;(DefaultMavenProje ctBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(Ljava/io/File;Lorg/apache/ma ven/artifact/repository/ArtifactRepository;Lorg/apache/maven/settings/Settings;L org/apache/maven/profiles/ProfileManager;)Lorg/apache/maven/project/MavenProject ;(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(Ljava/util/List;Lorg/ap ache/maven/artifact/repository/ArtifactRepository;ZLorg/apache/maven/settings/Se ttings;Lorg/apache/maven/profiles/ProfileManager;Z)Ljava/util/List;(DefaultMaven .java:447) at org.apache.maven.DefaultMaven.collectProjects(Ljava/util/List;Lorg/ap ache/maven/artifact/repository/ArtifactRepository;ZLorg/apache/maven/settings/Se ttings;Lorg/apache/maven/profiles/ProfileManager;Z)Ljava/util/List;(DefaultMaven .java:491) at org.apache.maven.DefaultMaven.getProjects(Lorg/apache/maven/execution /MavenExecutionRequest;Lorg/apache/maven/profiles/ProfileManager;)Ljava/util/Lis t;(DefaultMaven.java:351)
[jira] Closed: (MNG-2348) add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often
[ http://jira.codehaus.org/browse/MNG-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2348. -- Resolution: Won't Fix add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often - Key: MNG-2348 URL: http://jira.codehaus.org/browse/MNG-2348 Project: Maven 2 3 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.4 Reporter: james strachan Fix For: 3.x Could we have some simple alias on the command line to disable unit tests just like we have maven -o for offline. Don't much mind what it is - how about... -nt --no-testsDisables the junit tests in this build so to do a build without unit tests mvn -nt install -- 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-2323) Locked SNAPSHOT version ignored
[
http://jira.codehaus.org/browse/MNG-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2323:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
Locked SNAPSHOT version ignored
---
Key: MNG-2323
URL: http://jira.codehaus.org/browse/MNG-2323
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4, 3.0-alpha-7
Reporter: Joerg Schaible
Priority: Critical
Fix For: 3.0-alpha-7
We use for our tip revision (head revision of a branch) a snapshot version in
the form of:
_major.minor-SNAPSHOT_
If we make a (maintenance) release, we create a version like:
_major.minor.revision_
We manage our dependencies in a dependencyManagement section of a super POM,
where we define always the last released version of an artifact. A dependency
of an artifact that is always declared without explicit version unless it
makes usage of an unreleased version, then the child POM will be changed from
{code:xml}
dependency
groupIdgroup/group
artifactIdartifact/artifactId
dependency
{code}
to
{code:xml}
dependency
groupIdgroup/group
artifactIdartifact/artifactId
versionmajor.minor-SNAPSHOT/version
dependency
{code}
Unfortunately this does not work, Maven still prefers the released version.
Here in the example 2.0.0 instead of 2.0.-SNAPSHOT (snippet):
{noformat}
[INFO] [eclipse:eclipse]
[DEBUG] com.elsagsolutions.projects.components:es_logging:jar:1.0-SNAPSHOT
(selected for null)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0-SNAPSHOT:test
(applying version: 2.0.0;applying scope: test)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0.0:test (selected
for test)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (applying version: 2.1_3;)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (selected for test)
{noformat}
But it gets worse. Even if we try to lock the version in the child POM, it
does not work; the locked version is happily ignored:
{code:xml}
dependency
groupIdgroup/group
artifactIdartifact/artifactId
version[major.minor-SNAPSHOT]/version
dependency
{code}
Output from the example:
{noformat}
[INFO] [eclipse:eclipse]
[DEBUG] com.elsagsolutions.projects.components:es_logging:jar:1.0-SNAPSHOT
(selected for null)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0-SNAPSHOT:test
(setting version to: 2.0-SNAPSHOT from range: [2.0-SNAPSHOT,2.0-SNAPSHOT])
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0-SNAPSHOT:test
(applying version: 2.0.0;applying scope: test)
[DEBUG] com.elsagsolutions.commons:es_commons_test:jar:2.0.0:test (selected
for test)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (applying version: 2.1_3;)
[DEBUG] cglib:cglib-nodep:jar:2.1_3:test (selected for test)
{noformat}
First problem is, that 2.0.x is treated as nearer as 2.0-SNAPSHOT. This is
IMHO wrong. The algorithm should look, at which point in the version
numbering the SNAPSHOT part starts and ignore the further numbers in the
version of released artifacts. Additionally the locked version must be
honored in any case.
--
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-2356) Add timing information to integration tests
[ http://jira.codehaus.org/browse/MNG-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2356. -- Resolution: Fixed Add timing information to integration tests --- Key: MNG-2356 URL: http://jira.codehaus.org/browse/MNG-2356 Project: Maven 2 3 Issue Type: Improvement Components: Integration Tests Affects Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Trivial Fix For: 3.x Attachments: MNG-2356.diff Also document why using your installed maven to recompile this plugin is a bad idea :) -- 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-2356) Add timing information to integration tests
[ http://jira.codehaus.org/browse/MNG-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204224#action_204224 ] Jason van Zyl commented on MNG-2356: Timing information is present. Add timing information to integration tests --- Key: MNG-2356 URL: http://jira.codehaus.org/browse/MNG-2356 Project: Maven 2 3 Issue Type: Improvement Components: Integration Tests Affects Versions: 2.0.4 Reporter: Jerome Lacoste Priority: Trivial Fix For: 3.x Attachments: MNG-2356.diff Also document why using your installed maven to recompile this plugin is a bad idea :) -- 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-2396) Define profiles element in Maven POM Schema
[ http://jira.codehaus.org/browse/MNG-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2396. -- Resolution: Won't Fix Define profiles element in Maven POM Schema - Key: MNG-2396 URL: http://jira.codehaus.org/browse/MNG-2396 Project: Maven 2 3 Issue Type: Improvement Components: General Reporter: Xavier Dury Priority: Trivial Fix For: 3.x Currently, only the project element of the pom schema is declared as an element, others are complexTypes. As the profiles section of the pom can be externalized in a profiles.xml file, it would be great to use the same schema for validation and auto-completion by declaring profiles as a (root) element too. -- 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-2409) @requiresDependencyResolution re-resolves transitive dependencies
[
http://jira.codehaus.org/browse/MNG-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2409.
--
Resolution: Fixed
Fix Version/s: (was: 2.2.x)
3.x
@requiresDependencyResolution re-resolves transitive dependencies
-
Key: MNG-2409
URL: http://jira.codehaus.org/browse/MNG-2409
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Reporter: Stepan Roh
Fix For: 3.x
Attachments: test.rdr.zip
Consider this scenario:
project A
project B, depends on A
project C, to be compiled, depends on B
projects A and B are from artifact repository, project C is being compiled
Let's say that before phase compile of project C my plugin is called which
looks for all dependencies of C (in our case A and B) and change their file
(Artifact.setFile()). All those dependencies are already resolved. Then
compile:compile is run which has @requiresDependencyResolution compile which
leads to A being re-resolved = it loses my file, but B retains it:
original A.getFile() = a.jar
original B.getFile() = b.jar
changed A.getFile() = xa.jar
changed B.getFile() = xb.jar
after compile A.getFile() = a.jar
after compile B.getFile() = xb.jar
Attached archive contains all necessary source code (source of A, B, C and
test Mojo) to recreate the situation. Just do:
unzip test.rdr.zip
cd test.rdr
( cd project-a; mvn install )
( cd project-b; mvn install )
( cd maven-refile-plugin; mvn install )
( cd project-c; mvn install )
The output of last mvn install will be something like (edited for brevity):
[INFO] [refile:set-file {execution: set}]
[INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-b-1.0-SNAPSHOT.jar
[INFO] new file: .../project-b-1.0-SNAPSHOT.jar.new.jar
[INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-a-1.0-SNAPSHOT.jar
[INFO] new file: .../project-a-1.0-SNAPSHOT.jar.new.jar
[INFO] Compile classpath: [target\classes,
.../project-b-1.0-SNAPSHOT.jar.new.jar,
.../project-a-1.0-SNAPSHOT.jar.new.jar]
[INFO] [refile:show-file {execution: show-before-compile}]
[INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-b-1.0-SNAPSHOT.jar.new.jar
[INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-a-1.0-SNAPSHOT.jar.new.jar
[INFO] Compile classpath: [target\classes,
.../project-b-1.0-SNAPSHOT.jar.new.jar,
.../project-a-1.0-SNAPSHOT.jar.new.jar]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [refile:show-file {execution: show-after-compile}]
[INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-b-1.0-SNAPSHOT.jar.new.jar
[INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-a-1.0-SNAPSHOT.jar
[INFO] Compile classpath: [target\classes,
.../project-b-1.0-SNAPSHOT.jar.new.jar, .../project-a-1.0-SNAPSHOT.jar]
...
As you can see after compile is run, project A's file is back to original
value, but B retained new file. I think this is a strange behaviour and
should be changed to act one way or another, preferably that already resolved
dependencies are not re-resolved.
--
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-2409) @requiresDependencyResolution re-resolves transitive dependencies
[
http://jira.codehaus.org/browse/MNG-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204225#action_204225
]
Jason van Zyl commented on MNG-2409:
This is fixed as part of the work in 3.x. I don't think you really want to
attempt to fix this in 2.x.
@requiresDependencyResolution re-resolves transitive dependencies
-
Key: MNG-2409
URL: http://jira.codehaus.org/browse/MNG-2409
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Reporter: Stepan Roh
Fix For: 3.x
Attachments: test.rdr.zip
Consider this scenario:
project A
project B, depends on A
project C, to be compiled, depends on B
projects A and B are from artifact repository, project C is being compiled
Let's say that before phase compile of project C my plugin is called which
looks for all dependencies of C (in our case A and B) and change their file
(Artifact.setFile()). All those dependencies are already resolved. Then
compile:compile is run which has @requiresDependencyResolution compile which
leads to A being re-resolved = it loses my file, but B retains it:
original A.getFile() = a.jar
original B.getFile() = b.jar
changed A.getFile() = xa.jar
changed B.getFile() = xb.jar
after compile A.getFile() = a.jar
after compile B.getFile() = xb.jar
Attached archive contains all necessary source code (source of A, B, C and
test Mojo) to recreate the situation. Just do:
unzip test.rdr.zip
cd test.rdr
( cd project-a; mvn install )
( cd project-b; mvn install )
( cd maven-refile-plugin; mvn install )
( cd project-c; mvn install )
The output of last mvn install will be something like (edited for brevity):
[INFO] [refile:set-file {execution: set}]
[INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-b-1.0-SNAPSHOT.jar
[INFO] new file: .../project-b-1.0-SNAPSHOT.jar.new.jar
[INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-a-1.0-SNAPSHOT.jar
[INFO] new file: .../project-a-1.0-SNAPSHOT.jar.new.jar
[INFO] Compile classpath: [target\classes,
.../project-b-1.0-SNAPSHOT.jar.new.jar,
.../project-a-1.0-SNAPSHOT.jar.new.jar]
[INFO] [refile:show-file {execution: show-before-compile}]
[INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-b-1.0-SNAPSHOT.jar.new.jar
[INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-a-1.0-SNAPSHOT.jar.new.jar
[INFO] Compile classpath: [target\classes,
.../project-b-1.0-SNAPSHOT.jar.new.jar,
.../project-a-1.0-SNAPSHOT.jar.new.jar]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [refile:show-file {execution: show-after-compile}]
[INFO] Dependency: test.rdr:project-b:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-b-1.0-SNAPSHOT.jar.new.jar
[INFO] Dependency: test.rdr:project-a:jar:1.0-SNAPSHOT:compile
[INFO] resolved: true
[INFO] file: .../project-a-1.0-SNAPSHOT.jar
[INFO] Compile classpath: [target\classes,
.../project-b-1.0-SNAPSHOT.jar.new.jar, .../project-a-1.0-SNAPSHOT.jar]
...
As you can see after compile is run, project A's file is back to original
value, but B retained new file. I think this is a strange behaviour and
should be changed to act one way or another, preferably that already resolved
dependencies are not re-resolved.
--
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-2443) Don't download pom if artifact is already in the local repository
[ http://jira.codehaus.org/browse/MNG-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2443: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Don't download pom if artifact is already in the local repository - Key: MNG-2443 URL: http://jira.codehaus.org/browse/MNG-2443 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Carsten Ziegeler Assignee: Jason van Zyl Fix For: 3.0-alpha-7 There are many projects out there just providing their artifact without a pom (whether this is good or not is a different question). Now in this case m2 always tries to download a pom for those artifacts, even if the artifact itself is already in the local repository. And if you have several of those artifacts combined with more than one repository configured, then there are a lot of unnecessary download attempts. I think this falls into the same category as changing a pom in the repository (which should be forbidden) - so if for the first time the artifact is downloaded no pom available, then there will never be a pom for this specific artifact. -- 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-2452) parameter parse error
[ http://jira.codehaus.org/browse/MNG-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2452. -- Resolution: Won't Fix parameter parse error - Key: MNG-2452 URL: http://jira.codehaus.org/browse/MNG-2452 Project: Maven 2 3 Issue Type: Bug Components: Command Line Affects Versions: 2.0.3 Environment: ubuntu linux Reporter: Andrew Williams Priority: Minor Fix For: 2.2.x typing mvn -Uinstall will result on a forced update and then an install phase. This is incorrect (if we wish to be compatible with GNU type arguments) it should force mvn -U install. -Uinstall should imply 8 options, not 1 and the install command -- 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-2478) add filtered resource directories to super POM
[ http://jira.codehaus.org/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2478: --- Fix Version/s: (was: 2.3.x) 3.0-alpha-7 Should be easy to add and makes sense. add filtered resource directories to super POM -- Key: MNG-2478 URL: http://jira.codehaus.org/browse/MNG-2478 Project: Maven 2 3 Issue Type: New Feature Components: POM Affects Versions: 2.0.4 Environment: any Reporter: Jörg Hohwiller Fix For: 3.0-alpha-7 The super POM contains default folders for resources that are NOT filtered (src/main/resources and src/test/resources). If one (additionally) needs a filtered resources folder, it needs to override the default and therefore has to add all default folders if he does NOT want to loose the defaults. To make this easier my suggestion is to add filtered resource folders to the super POM. This should also fit to the philosophy of maven that aims to have defaults and only declare as little custom configuration as needed. My personal favorite for the foldernames would be templates but to make things more obvious to the user maybe filtered-resources would be better. Actually I do not care to much about the name... So the resources in the super POM should look like this: resources resource directorysrc/main/resources/directory /resource !-- BEGIN: addition -- resource directorysrc/main/filtered-resources/directory filteringtrue/filtering /resource !-- END: addition -- /resources testResources testResource directorysrc/test/resources/directory /testResource !-- BEGIN: addition -- testResource directorysrc/test/filtered-resources/directory filteringtrue/filtering /testResource !-- END: addition -- /testResources -- 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-2500) Zip files are not included in the test classpath
[ http://jira.codehaus.org/browse/MNG-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2500. -- Resolution: Won't Fix Zip files are not included in the test classpath Key: MNG-2500 URL: http://jira.codehaus.org/browse/MNG-2500 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: windows xp Reporter: rudi grasmuck Fix For: 2.2.x when i added a dependency that was zip file egdependency groupIdhsqldb/groupId artifactIdhsqldb/artifactId version1.7.3.0/version scopeprovided/scope typezip/type /dependency this file was not included in the test classpath and so the test would not pass -- 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-2504) explore how provided app server deps map to app server platform definitions in Netbeans IDE.
[ http://jira.codehaus.org/browse/MNG-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2504. -- Resolution: Won't Fix explore how provided app server deps map to app server platform definitions in Netbeans IDE. Key: MNG-2504 URL: http://jira.codehaus.org/browse/MNG-2504 Project: Maven 2 3 Issue Type: Sub-task Components: Dependencies Reporter: Milos Kleint Assignee: Milos Kleint Fix For: 3.x see subject, could be important for IDE integration fo j2ee maven projects. -- 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-2504) explore how provided app server deps map to app server platform definitions in Netbeans IDE.
[ http://jira.codehaus.org/browse/MNG-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204227#action_204227 ] Jason van Zyl commented on MNG-2504: Netbeans specific. explore how provided app server deps map to app server platform definitions in Netbeans IDE. Key: MNG-2504 URL: http://jira.codehaus.org/browse/MNG-2504 Project: Maven 2 3 Issue Type: Sub-task Components: Dependencies Reporter: Milos Kleint Assignee: Milos Kleint Fix For: 3.x see subject, could be important for IDE integration fo j2ee maven projects. -- 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-2580) UNC in MAVEN_HOME not working
[ http://jira.codehaus.org/browse/MNG-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2580: --- Fix Version/s: (was: 2.2.x) 3.0-alpha-7 Should be fixed. Validate. UNC in MAVEN_HOME not working - Key: MNG-2580 URL: http://jira.codehaus.org/browse/MNG-2580 Project: Maven 2 3 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Windows XP Reporter: Remy COQUEUGNIOT Priority: Blocker Fix For: 3.0-alpha-7 Maven2 is installed in a corporate server : SERVER From my computer, this installation is accesible on a network share : \\SERVER\MAVEN2 From a command line I setup MAVEN_HOME with this UNC: set MAVEN_HOME=\\SERVER\MAVEN2 And put it in the PATH set PATH=%MAVEN_HOME%\bin;%PATH% When I try to build any projects, maven is unable to acces my global settings which is stored in %MAVEN_HOME%\conf\settings.xml But when I mount a network share to this UNC: net use Z: \\SERVER\MAVEN2 ...Setup MAVEN_HOME ... set MAVEN_HOME=Z:\ ...And put it in the PATH ... set PATH=%MAVEN_HOME%\bin;%PATH% The global settings.xml is read. This useCase seems OK with Maven 1. mvn -X doesn't give too any informations about the final %MAVEN_HOME%\conf which is used. But it prints the plugin-registry.xml locations which are based on the %MAVEN_HOME% In this case \\SERVER\MAVEN2 is badly transformed in C:\SERVER\MAVEN2 : set MAVEN_HOME=\\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4 mvn clean -X (...) [DEBUG] Building Maven global-level plugin registry from: 'C:\frmlefsi20\inet_dev\DEVPLATFORM\maven-2.0.4\bin\..\conf\plugin-registry.xml' (...) Thanks for your support and this great tool ! -- 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-2581) Mojo's with @execute don't get configured with executedProject
[
http://jira.codehaus.org/browse/MNG-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2581:
---
Fix Version/s: (was: 3.x)
3.0-alpha-7
Mojo's with @execute don't get configured with executedProject
--
Key: MNG-2581
URL: http://jira.codehaus.org/browse/MNG-2581
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Reporter: Kenney Westerhof
Fix For: 3.0-alpha-7
Not sure if this is a bug or an improvement, but here's a scenario:
A custom plugin defines a MavenProject property with a timestamp. That
timestamp
is used in finalName${project.artifactId}-${timestamp}/finalName.
During the normal plugin execution, this field is evaluated correctly.
When running mvn assembly:assembly, the normal (forked) lifecycle also
functions correctly.
But the assembly Mojo is configured with the original MavenProject, that
doesn't have the ${timestamp} property,
so the finalName parameter on the assembly mojo will be someArtifact-null.
A tough problem, but it goes further: Ideally you never want to use
${project} as a parameter, but
the objects fields directly. Say you want to use the source roots and define
that as a parameter. Then you
never get access the generated-sources unless you manually examine the
executedProject.
Right now, mojo's have to use different logic depending on whether they
specify @execute phase=X,
(and examine fields of the executedProject).
Can we drop the original MavenProject object and replace that with
executedProject instance, so we only have
1 instance of MavenProject?
Or, if there are plugins that MUST use the original MavenProject, or use both
MavenProject instances (we might
want to scan all existing mojo's to see what they do), can we add
a plugin flag that specifies that that mojo must be configured using the
executedProject instead?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2584) Rebuild on pom change
[ http://jira.codehaus.org/browse/MNG-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2584: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 Rebuild on pom change - Key: MNG-2584 URL: http://jira.codehaus.org/browse/MNG-2584 Project: Maven 2 3 Issue Type: Improvement Components: Design, Patterns Best Practices Reporter: Kenney Westerhof Fix For: 3.0-alpha-7 After a succesful build, all classes are compiled. Following builds won't recompile the classes since the sources haven't changed. When a user changes a dependency in the pom and then mvn installs, the sources aren't checked with the modified dependency. I propose we save a timestamp (or the pom itself) in target/ for each build, and let plugins that do some sort intelligent checking take this into account. There are a few options: - define a default location for the pom and let plugins implement timestamp or content checking as they please - define some api to ask if the project has changed - bind the clean plugin to some startup phase and let it auto-clean if the pom (or possibly parent poms/dependent poms) have changed. -- 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-2643) Unlimited number of version digits
[ http://jira.codehaus.org/browse/MNG-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2643. -- Resolution: Won't Fix Unlimited number of version digits Key: MNG-2643 URL: http://jira.codehaus.org/browse/MNG-2643 Project: Maven 2 3 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.4 Reporter: Jonas Olsson Fix For: 3.x Currently Maven only handles three digit versions, but that seems to be an artificial limit, not a technical one. Couldn't the version ordering/comparison be extend to an arbitrary number of digits? -- 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-2675) add getModules() method which return a MavenProject List instead of module name String list
[ http://jira.codehaus.org/browse/MNG-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2675: --- Fix Version/s: (was: 3.x) 3.0-alpha-7 add getModules() method which return a MavenProject List instead of module name String list --- Key: MNG-2675 URL: http://jira.codehaus.org/browse/MNG-2675 Project: Maven 2 3 Issue Type: Improvement Components: POM Affects Versions: 2.0.4 Environment: Maven 2.0.4, Windows 2000 Reporter: David Vicente Fix For: 3.0-alpha-7 Hi, i try to develop a dashboard report plugin. But i have a problem with a multi-project pom which i used to test my plugin. I have a master project with modules which have some modules or project. Until now, i get the modules list with project.getModules() method and i compare each module name with the project name that i get with project.getCollectedProjects() method. And for each MavenProject object i retreive, i repeat the last algorithm (getModules() .) all module names are the same as ArtifactId and my plugin work well. But with this new project, the module names and ArtifactId are different. and i can't retreive MavenProjects which are direct module of my pom. can you add a method to MavenProject object which return the list of modules as MavenProject object instead of String object ? -- 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: (MCHANGES-188) Announcement collides with ${changes.version} property
[
http://jira.codehaus.org/browse/MCHANGES-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-188.
Resolution: Not A Bug
One thing I do to avoid problems like this is to avoid using dots when naming
properties. So in your example I would name the property changesVersion
instead of changes.version.
We have a naming convention for plugin parameters that are specified on the
command line. It looks loosely like this:
plugin-name.property-name
It isn't implemented everywhere, but at least new parameters use that
convention. So staying away from naming your own properties in that way can
help you avoid confusion.
Announcement collides with ${changes.version} property
--
Key: MCHANGES-188
URL: http://jira.codehaus.org/browse/MCHANGES-188
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: announcement
Affects Versions: 2.2
Reporter: Sebastian Hoß
When you set the ${changes.version} property manually (e.g. to specify the
version of the changes plugin itself) the changes-plugin uses the given value
as the projects version and fails if you don't have a matching release with
the exact same version number.
This behavior is AFAIK not documented anywhere and should either be changed
or documented. I stumbled upon this yesterday and wrote an mail with further
information and a stack trace for this here:
http://maven.markmail.org/message/mg2qfnd4lw53larn
The plugins documentation[1] itself says that ${project.version} is the
default value for the version field, however the code[2] tells that version
is set to the expression=${changes.version} with a
default-value=${project.version}. So this bug only affects people who
have defined a ${changes.version} property. Changing the name of the property
resolves this.
This only affects the announcement goals, jira-report along mvn site runs
fine which may be a little confusing for users who have a running mvn site
configuration and now want to add announcement mails but run into this
problem (like myself in this case).
[1]:
http://maven.apache.org/plugins/maven-changes-plugin/announcement-generate-mojo.html
[2]:
http://maven.apache.org/plugins/maven-changes-plugin/xref/org/apache/maven/plugin/announcement/AnnouncementMojo.html#82
--
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-2701) Please add Fortuity to central Maven repository
Please add Fortuity to central Maven repository --- Key: MAVENUPLOAD-2701 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2701 Project: Maven Upload Requests Issue Type: Wish Reporter: Jeroen Steenbeeke I would like to request that the following line be added to the automatic sync list: com.fortuityframework,mavens...@web.sourceforge.net:/home/groups/f/fo/fortuity/htdocs/repo/,rsync_ssh,Jeroen Steenbeeke,j.steenbeeke...@gmail.com Proof of domain ownership: http://www.whois.net/whois/fortuityframework.com If there is anything further I need to do, or any changes I need to make, just let me know. -- 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-4368) DefaultArtifactInstaller should only overwrite files if timestamp has changed
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204235#action_204235 ] Benjamin Bentmann commented on MNG-4368: Revised in [r894114|http://svn.apache.org/viewvc?view=revisionrevision=894114] to have artifact installation happen if any of the following conditions are met: * destination does not exist * artifact type is pom * destination has different timestamp than source * destination has different length than source DefaultArtifactInstaller should only overwrite files if timestamp has changed - Key: MNG-4368 URL: http://jira.codehaus.org/browse/MNG-4368 Project: Maven 2 3 Issue Type: Improvement Environment: Linux, JDK 1.5 Reporter: Johannes Martin Fix For: 2.2.2, 3.0-alpha-3 install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build process. -- 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-2702) org.innobuilt,rsync://innobuilt.org::maven2,rsync,Jesse Piascik,je...@piascik.net,,
org.innobuilt,rsync://innobuilt.org::maven2,rsync,Jesse Piascik,je...@piascik.net,, - Key: MAVENUPLOAD-2702 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2702 Project: Maven Upload Requests Issue Type: Wish Reporter: Jesse Piascik org.innobuilt,rsync://innobuilt.org::maven2,rsync,Jesse Piascik,je...@piascik.net,, -- 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
