Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
3.0-alpha-2
-
None
-
None
-
n/a
Description
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