[
http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116073
]
John Casey commented on MNG-3311:
---------------------------------
What makes me cringe about using dependencyManagement for plugin deps (even
those brought in as plugin-level deps in the consumer's POM) is that all direct
plugin dependencies currently need to be aggregated and then resolved
transitively as a group in order to avoid the potential for version conflicts
in the nth-level transitive dependencies of that original collection.
Originally, I think the plugin's own deps and those specified in the
plugin-level of the consumer POM were resolved separately. While this would
allow depMgmt to be used for those specified in the consumer POM, it still
leaves the door open for version conflicts in non-direct dependencies...that
is, UNLESS we can fix artifact resolution to allow multiple passes to
incorporate managed dependency versions in some cases but not others, and still
resolve all version conflicts in one fell swoop. I mention this, because I know
the maven-artifact refactoring that Jason is involved with should allow
something like it, where this sort of dependency resolution information
(version conflicts, managed versions, etc.) can accumulate on the graph nodes
and edges where it belongs, then be activated at the end to extract the
dependency closure to be used.
> Better/easier way to override plugin dependencies
> -------------------------------------------------
>
> Key: MNG-3311
> URL: http://jira.codehaus.org/browse/MNG-3311
> Project: Maven 2
> Issue Type: Improvement
> Components: Dependencies, Plugins and Lifecycle
> Affects Versions: 2.0.8
> Reporter: Steve Ebersole
> Attachments: antlr-problem-part2.tar.gz
>
>
> Currently, the only way to override the version of a dependency used by a
> plugin is to "fully specify the dependency" in the
> build/plugins/plugin/dependencies section. This is difficult for cases where
> the project itself depends on said dependency as well. Take the case of the
> antlr-maven-plugin at codehaus (as this is where I experienced the problem).
> The plugin is used to generate parsers as part of the build using Antlr. The
> project, itself, would also need to define Antlr as a dependency since it
> would then have a compile and runtime dependency on Antlr. So, at the very
> least, we end up with two definitions of the Antlr dependency.
> For background, defining the same dep twice is not that big of a deal. I
> "dealt with it" by using a property for the Antlr version to use, and then
> referencing that in the dependency definitions. Where it started to get very
> unsavory for me was when I started moving my "base line" deps into a
> <dependencyManagement/> section, and especially when that
> <dependencyManagement/> was defined in the parent pom. The issue I ran into
> was that I could no longer use a property (if I defined it in the parent, it
> is not inherited into the child where i need to define the plugin). The next
> thing I tried that I "reasonably" thought would work was to define the
> <dependencyManagement/> section in the parent, and in the child to define the
> dependencies/dependency without the <version/> tag and then to try the same
> in the build/plugins/plugin/dependencies/dependency section. However that is
> apparently not valid in the build/plugins/plugin/dependencies/dependency
> (org.apache.maven.BuildFailureException: For artifact {antlr:antlr:null:jar}:
> The version cannot be empty.)
> I am not exactly sure what the "best" option is. I certainly believe that
> the following should work (which is what I described above):
> <dependencyManagement>
> <dependency>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> <version>2.7.6</version>
> </dependency>
> </dependencyManagement>
> <build>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>antlr-maven-plugin</artifactId>
> <version>${antlrPluginVersion}</version>
> <dependencies>
> <dependency>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> </dependency>
> </dependencies>
> ...
> </plugin>
> </plugins>
> </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
