You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Steve Ebersole (JIRA)" <ji...@codehaus.org> on 2007/12/05 18:12:57 UTC
[jira] Created: (MNG-3311) Better/easier way to override plugin
dependencies
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
[jira] Commented: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "Steve Ebersole (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "Steve Ebersole (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115943 ]
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: 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
[jira] Commented: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "Steve Ebersole (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115954 ]
Steve Ebersole commented on MNG-3311:
-------------------------------------
FYI...
After verifying some more, it appears the overriding in general does not work at all in 2.0.8. I was still pointing at a 2.1-SNAPSHOT Jason built for me with this change when he found the cause of the overriding not working. My understanding was that this was also supposed to make it into 2.0.8, but that does not appear to be the case.
To be clear, even the following will not work on 2.0.8:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>antlr-maven-plugin</artifactId>
<version>${antlrPluginVersion}</version>
<dependencies>
<dependency>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
<!-- explicit version override -->
<version>2.7.6</version>
</dependency>
</dependencies>
...
</plugin>
</plugins>
</build>
> 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
[jira] Commented: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Updated: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated MNG-3311:
------------------------------
Fix Version/s: 2.1
> 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
> Fix For: 2.1
>
> 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
[jira] Updated: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "Steve Ebersole (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Ebersole updated MNG-3311:
--------------------------------
Attachment: antlr-problem-part2.tar.gz
> 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
[jira] Commented: (MNG-3311) Better/easier way to override plugin
dependencies
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ 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