[
http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194914#action_194914
]
Neale edited comment on MNG-4391 at 10/15/09 3:11 PM:
------------------------------------------------------
>> You may configure different versions of X for downloading, but it's still
>> artifact X.
That is exactly the problem. If my project, A depends on X which has a
transitive dependency on Y, then being able to vary the version of Y does not
allow us to substitute (yet does allow us to break the software by allowing us
to regress a version from, say 2.1 to 1.3.
Please notice ththat other's are now voting and consider this request.
It's an option, and you are pre-judging the intent of an artifact's developer
to presume that they, _under no circumstances_ want anyone to replace a
dependency with an alternative that may be
- instrumented
- woven
- enhanced (e.g. the trunk committers don't have the time/inclination to
implement a feature or fix that you need)
- bug fixed in a (local or public) branch
- project naturally branched and the branch became the mainstream version
That presumption is simply not true.
So. I ask again. Can you please tell me how I, in a way where my intent is as
clear as water, replace Apache Commons Logging with the SLF4J Apache Commons
Logging integration artifact?
was (Author: neale87):
>> You may configure different versions of X for downloading, but it's
still artifact X.
That is exactly the problem. If my project, A depends on X which has a
transitive dependency on Y, then being able to vary the version of Y does not
allow us to substitute (yet does allow us to break the software by allowing us
to regress a version from, say 2.1 to 1.3.
Please notice ththat other's are now voting and consider this request.
It's an option, and you are pre-judging the intent of an artifact's developer
to presume that they, _under no circumstances_ want anyone to replace a
dependency with an alternative that may be
- instrumented
- woven
- enhanced / optimised
- bug fixed in a branch
That presumption is simply not true.
So. I ask again. Can you please tell me how I, in a way where my intent is as
clear as water, replace Apache Commons Logging with the SLF4J Apache Commons
Logging integration artifact?
> DependencyManagement should allow <replaceWith> to manage use of re-named,
> woven, instrumented or compatible artifacts
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4391
> URL: http://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2
> Issue Type: Improvement
> Components: Dependencies
> Affects Versions: 2.2.1
> Reporter: Neale
>
> [if only this was a later version of JIRA I'd have not lost all of what I
> just typed, as I could use Mylyn instead of the web UI. here goes again...]
> The challenge of using a different artifact instead of the one that is
> specified in a POM that you are consuming is not an easy one.
> Examples where this hits uses is:
> - the artifact name and packaging changes that Spring made at 2.5.6A (which
> was a big improvement)
> - wanting to use SLF4J instead of Apache commons logging (i.e. use something
> that provides the same API, but is an entirely different project)
> - wanting to use your own derivation of a public artifact
> - wanting to use a woven/instrumented version of a public artifact
> The current approach to replacing, say org.springframework : spring-beans
> with org.springframework : org.springframework.beans is to do ('scuse the
> shorthand):
> {code:xml}
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>com.sun.jersey.contribs</groupId>
> <artifactId>jersey-spring</artifactId>
> <exclusions>
> org.springframework : spring-beans
> </exclusions>
> </dependency>
> ... repeat for every artifact that uses spring-beans, and then add more
> if adding another artifact
> </dependencies>
> </dependencyManagement>
> {code}
> to exclude it, and then globally include the replacement using:
> {code:xml}
> <dependencies>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>org.springframework.beans</groupId>
> <version>${spring.version}</version>
> </dependency>
> </dependencies>
> {code}
> This is error prone, and could be made far easier by an extension to
> dependencies, which would remove the need to know what artifacts
> (jersey-spring in the above example) use the artifact that you are replacing.
> Here's how it would look:
> {code:xml}
> <dependencyManagement>
> <!-- this declares the version we want to use if this artifact is in use -->
> <dependencies>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>org.springframework.beans</groupId>
> <version>${spring.version}</version>
> </dependency>
> <!-- This deals with artifact name change -->
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>spring-beans</groupId>
> <replaceWith> <!-- list of dependency elements -->
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactid>org.springframework.beans</groupId>
> </dependency>
> <!-- more dependency elements could be added here if an artifact
> has been split -->
> </replaceWith>
> </dependency>
> </dependencies>
> {code}
> NOTE:
> - Nothing is specified in <dependencies> so no artifacts are globally added
> where they may not be needed. This means we can develop a project wide
> parent pom.xml.
> - Artifacts can have been split and merged
> - Derived artifacts, such as instrumented ones can easily be substituted, and
> could be selectively substituted using profiles.
--
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
