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
Issue Type: New Feature
Components: Dependencies, IDEs, Plugin API, Plugins and Lifecycle, POM
Affects Versions: 2.0.9
Environment: n/a
Reporter: Steve Ebersole
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
