[
http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115945
]
Steve Ebersole commented on MNG-3311:
-------------------------------------
John, regarding the example from my original description... What I thought
this would do was to find the dependency in my local project dependencies and
force that on the plugin just as if I had specified I version. Note that that
is subtly different than "2. Forcing versions inside the plugin's dependency
closure using dependencyManagement:. Now, you know the code base far better
than me, so perhaps seeing that snippet, you expect something else to happen;
but this is what I expected as a user and in the absence of any documentation
of what would happen.
> 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
