maven-issues mailing list archives

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

    [ http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115939
] 

John Casey commented on MNG-3311:
---------------------------------

I already mentioned this on IRC, but I'll restate it here so it gets captured...

It seems to me there are two things going on in the example above, and I'd like to address
them separately:

1. Overriding a dependency from the plugin's own POM inside a plugin-level dependency in the
local POM (the plugin consumer). In this case, I can definitely see why it's sometimes desired,
but it seems dangerous to me. How can you say that the plugin won't exhibit subtle bugs when
you replace one of its dependencies with a different version? Subtle bugs would be far worse
than an out-and-out NoSuchMethodError, since it could lead to quite a lot of time spent debugging
the plugin itself, or the build itself, all because of a basic incompatibility.

In cases like antlr, where the project has to have a dependency on antlr to function, it seems
to make more sense to me to have the plugin require the project dependency (antlr in this
case), and then incorporate it in the classloader that is used to call the tool. This provides
somewhat more flexibility, since the invocation API is a smaller section of code in which
to guarantee compatibility from version to version, and it also allows the type of variance
that Steve needs without resorting to mystical contortions inside the build tool. Possibly
the build tool - or a related, shared component - can aid the development of these sorts of
plugins more effectively somehow, possibly by providing an abstract Mojo implementation that
collects the parameters, constructs a new classloader including a certain project dependency,
and launches the "real" mojo with the collected parameters...I don't know.

2. Forcing versions inside the plugin's dependency closure using dependencyManagement from
the local project. To me, this is even more dangerous, since it will inevitably result in
a project's dependencyManagement having unintended side effects on the plugins used to build
the project. For instance, if your project set uses commons-collections throughout, it may
want to centralize the version in dependencyManagement. However, in doing so, any plugin that
uses commons-collections would be influenced by this dependencyManagement specification. If
the plugin needs 2.x and the project needs 3.x, this is a major problem.

I'm currently searching for plugins that fit this scenario, so I can build a test case that
displays the use case concretely. However, until I find a way to grab the dependency closure
for an arbitrary plugin this will be slow going. I'll post my results, of course.

> 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
>
> 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