maven-issues mailing list archives

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

    [ 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

       

Mime
View raw message