[
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
