You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Neale (JIRA)" <ji...@codehaus.org> on 2009/10/12 16:10:27 UTC
[jira] Created: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Paul Benedict (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194428#action_194428 ]
Paul Benedict commented on MNG-4391:
------------------------------------
I don't think replacing is a good idea since it introduces a kind of relocation logic. Regardless, would adding global exclusions (MNG-1977) help?
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Paul Benedict (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197871#action_197871 ]
Paul Benedict commented on MNG-4391:
------------------------------------
Stevo, that is a very interesting idea.
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197940#action_197940 ]
Neale commented on MNG-4391:
----------------------------
Agree to. That'd do the trick and sounds like it'd be a helpful way of ensuring tools such as m2e can visualise the results easily. Nice one.
> 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
[jira] (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible artifacts
Posted by "Sören Chittka (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296553#comment-296553 ]
Sören Chittka commented on MNG-4391:
-------------------------------------
+1 for having this in 3.1
I really like the syntax suggested above. It makes clear what is intended. If this is to much 'smoke-and-mirrors' a decent IDE can make visible what is going on.
> DependencyManagement should allow <replaceWith> to manage use of re-named, woven, instrumented or compatible artifacts
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4391
> URL: https://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
> Affects Versions: 2.2.1
> Reporter: Neale
> Fix For: Issues to be reviewed for 3.x
>
>
> [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, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4391) DependencyManagement should
allow to manage use of re-named, woven, instrumented or
compatible artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194429#action_194429 ]
Neale edited comment on MNG-4391 at 6/17/10 2:37 AM:
-----------------------------------------------------
I don't get your objection. What's the 'relocation logic' problem?
Direct artifact substitution is what in many cases the developer needs, so surely the "good idea" test is whether it makes Maven easier to use and maintain.
If you look at the comments on MNG-1977, you'll find David Jencks and Kees de Kooter suggesting the same as me.
was (Author: neale87):
I don't get your objection. What's the 'relocation logic' problem?
Direct artifact substitution is what in many cases the developer needs, so surely the "good idea" test is whether it makes Maven easier to use and maintain.
If you look at the comments on MNG-1977, you'll find David Jencks and Kees de Kooter suggesting the same is me.
> 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 & 3
> 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
[jira] Issue Comment Edited: (MNG-4391) DependencyManagement should
allow to manage use of re-named, woven, instrumented or
compatible artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194540#action_194540 ]
Neale edited comment on MNG-4391 at 10/13/09 8:30 AM:
------------------------------------------------------
I think that's a rather personal point of view, if you don't mind me saying. On that basis, none of us would make use of AspectJ or proxies.
It is _already_ the case that a child project configured to download X gets Y, as that's what we're actually trying to do. The problem is that it doesn't actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says download X" is relevant to what we as developers need. We can easily end up with multiple versions of the same API on the classpath because the exclusions weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us): _the implementation of org.apache.commons.logging that I want to use in my build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging_, or, if we want one that has been built as a valid OSGi bundle: _org.slf4j:com.springsource.slf4j.org.apache.commons.logging_.
What we certainly *don't* want is to have to repeat the exclude on an ad-hoc basis, and nor do we want the _meaning_ lost in separating out an exclusion with a global inclusion (which is not always wanted either - e.g. for corporate standards).
Can you please tell me how you propose to satisfy this use case, if you still have your objections to my solution. It's all very well disagreeing, but it would be useful to offer a better solution in it's place.
was (Author: neale87):
I think that's a rather personal point of view, if you don't mind me saying. On that basis, none of us would make use of AspectJ or proxies.
It is _already_ the case that a child project configured to download X gets Y, as that's what we're actually trying to do. The problem is that it doesn't actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says download X" is relevant to what we as developers need. We can easily end up with multiple versions of the same API on the classpath because the exclusions weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us): _the implementation of org.apache.commons.logging that I want to use in my build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging_, or, if we want one that has been built as a valid OSGi bundle: _org.slf4j:com.springsource.slf4j.org.apache.commons.logging_.
What we certainly *don't* want is to have to repeat the exclude on an ad-hoc basis, and nor do we want the _meaning_ lost in separating out an exclusion with a global inclusion (which is not always wanted either - e.g. for corporate standards).
Can you please tell me how you propose to satisfy this use case, if you still have your objections to my solution, please. It's all very well disagreeing, but it would be useful to offer a better solution in it's place.
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Stevo Slavic (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195984#action_195984 ]
Stevo Slavic commented on MNG-4391:
-----------------------------------
Why not just support dependencies section for a dependency, like what's already supported for build plugins (and hopefully will be in v3 supported for reporting plugins too)? One could then for a given dependency configure set of exclusions and add dependencies too out of which some could be exclusion replacements. Dependency POM no longer reflects reality once one adds exclusions to it, so adding more dependencies to it will IMO not be much more difference on that aspect - there's always dependency:tree and dependency:analyze, and IDE plugins can visualize effective POM.
> 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
[jira] Issue Comment Edited: (MNG-4391) DependencyManagement should
allow to manage use of re-named, woven, instrumented or
compatible artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Issue Comment Edited: (MNG-4391) DependencyManagement should
allow to manage use of re-named, woven, instrumented or
compatible artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197940#action_197940 ]
Neale edited comment on MNG-4391 at 11/11/09 4:43 AM:
------------------------------------------------------
Agree too. That'd do the trick and sounds like it'd be a helpful way of ensuring tools such as m2e can visualise the results easily. Nice one.
was (Author: neale87):
Agree to. That'd do the trick and sounds like it'd be a helpful way of ensuring tools such as m2e can visualise the results easily. Nice one.
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Paul Benedict (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194601#action_194601 ]
Paul Benedict commented on MNG-4391:
------------------------------------
>> I think that's a rather personal point of view, if you don't mind me saying.
Of course it's a personal point of view.
>> It is already the case that a child project configured to download X gets Y
The use case is limited. X represents the artifact. You may configure different versions of X for downloading, but it's still artifact X. Maven does provide relocation support, but it's controlled by the publisher of the artifact. You are expanding its use to give people the ability to relocate (temporarily) for the current execution. Well, I don't think it's a good idea because it makes the POM unclear what is going on.
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Paul Benedict (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194433#action_194433 ]
Paul Benedict commented on MNG-4391:
------------------------------------
My objection is that the POM no longer reflects reality. If a POM can relocate an artifact, a child project configured to download X gets Y, but when I look at the child POM, it says download X. It's too much smoke-and-mirrors for me and is bound to lead to confusion.
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194914#action_194914 ]
Neale commented on MNG-4391:
----------------------------
>> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194540#action_194540 ]
Neale commented on MNG-4391:
----------------------------
I think that's a rather personal point of view, if you don't mind me saying. On that basis, none of us would make use of AspectJ or proxies.
It is _already_ the case that a child project configured to download X gets Y, as that's what we're actually trying to do. The problem is that it doesn't actually say "replace X with Y". It says: "don't download X".
You are mistaken in thinking that "when I look at the child POM, it says download X" is relevant to what we as developers need. We can easily end up with multiple versions of the same API on the classpath because the exclusions weren't set on every child.
At some point in our project we want to say something like (as OSGi gives us): _the implementation of org.apache.commons.logging that I want to use in my build and runtime can be found in org.slf4j:slf4j:org.apache.commons.logging_, or, if we want one that has been built as a valid OSGi bundle: _org.slf4j:com.springsource.slf4j.org.apache.commons.logging_.
What we certainly *don't* want is to have to repeat the exclude on an ad-hoc basis, and nor do we want the _meaning_ lost in separating out an exclusion with a global inclusion (which is not always wanted either - e.g. for corporate standards).
Can you please tell me how you propose to satisfy this use case, if you still have your objections to my solution, please. It's all very well disagreeing, but it would be useful to offer a better solution in it's place.
> 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
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280456#comment-280456 ]
Neale commented on MNG-4391:
----------------------------
Can we please have a resolution to this issue for 3.1. The challenge of artifacts where we want provide an alternative implementation needs to be clear. The POM configuration should represent the intent: "Where dependency groupId:artifactId is specified, I want to use replacementGroupId:replacementArtifactId instead"
> DependencyManagement should allow <replaceWith> to manage use of re-named, woven, instrumented or compatible artifacts
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4391
> URL: https://jira.codehaus.org/browse/MNG-4391
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies
> Affects Versions: 2.2.1
> Reporter: Neale
> Fix For: Issues to be reviewed for 3.x
>
>
> [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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4391) DependencyManagement should allow
to manage use of re-named, woven, instrumented or compatible
artifacts
Posted by "Neale (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194429#action_194429 ]
Neale commented on MNG-4391:
----------------------------
I don't get your objection. What's the 'relocation logic' problem?
Direct artifact substitution is what in many cases the developer needs, so surely the "good idea" test is whether it makes Maven easier to use and maintain.
If you look at the comments on MNG-1977, you'll find David Jencks and Kees de Kooter suggesting the same is me.
> 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