maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Ebersole (JIRA)" <>
Subject [jira] Commented: (MNG-3311) Better/easier way to override plugin dependencies
Date Wed, 05 Dec 2007 18:03:57 GMT


Steve Ebersole commented on MNG-3311:

I uploaded a simple project illustrating some of these issues.  Please note that making this
in a multi-project build exacerbates this problem because we can no longer share the property
uses to unify the antlr version being used.

> Better/easier way to override plugin dependencies
> -------------------------------------------------
>                 Key: MNG-3311
>                 URL:
>             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:
For more information on JIRA, see:


View raw message