You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2009/03/01 15:10:40 UTC
MNG-4056, please comment
Hi,
I recently created a patch for MNG-4056 and would appreciate some
comments whether that's the proper way to address the issue.
In short, this issue is about the subtle difference between
<dependency>
<groupId>gid</groupId>
<artifactId>aid</artifactId>
<version>0.1</version>
<classifier>tests</classifier>
</dependency>
and
<dependency>
<groupId>gid</groupId>
<artifactId>aid</artifactId>
<version>0.1</version>
<type>test-jar</type>
</dependency>
i.e. <type>test-jar</type> vs. <classifier>tests</classifier>. While
both declarations work during builds of the consumer project that run up
to the "install" phase, only the latter declaration will allow proper
dependency resolution from the reactor during an earlier lifecycle phase
like "package" (see also comments in MNG-2045 [0]).
The cause for this difference is that resolution from the reactor
matches artifacts by their dependency conflict id which has the form
gid:aid:type:classifier. For the first dependency declaration above, the
type is "jar" which doesn't match the type "test-jar" as used for the
attached test JAR.
In case matching by dependency conflict id fails, the proposed patch
falls back to another id I called repository conflict id (well, it
needed to have a name...). The important difference is that the
repository conflict id has the form gid:aid:extension:classifier, i.e.
uses the file extension instead of the type.
The rationale for this approach is the observation that the repository
layout does not use the artifact type but the file extension to
distinguish files. In other words, the ids
gid:aid:test-jar:tests:0.1
and
gid:aid:jar:tests:0.1
get mapped to the same physical file in the repository, namely
gid/aid/0.1/aid-0.1/aid-0.1-tests.jar
i.e. there's an aliasing effect in the repository which the patch mimics
for dependency resolution from the reactor.
It solves the problem from a user's perspective but I'm not sure whether
this kind of artifact identity is clean from a design perspective. WDYT?
Benjamin
[0]
http://jira.codehaus.org/browse/MNG-2045?focusedCommentId=152064&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_152064
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-4056, please comment
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian E. Fox wrote:
> Seems logical to me. I don't know why there are these special mappings
> in the first place.
Not sure either, possibly to control the addedToClasspath flag of the
artifact handler [0] (which is false for java-source but true for
javadoc...).
> Sources is the other one that comes to mind... if
> true you should handle that the same.
These are the artifacts attached by Apache plugins I know of:
- maven-ejb-plugin: EJB client JAR as type "ejb-client"
- maven-jar-plugin: test JAR as type "test-jar"
- maven-javadoc-plugin: javadoc JAR as type "javadoc"
- maven-source-plugin: main/test source JAR as type "java-source"
All of these end up as files with extension ".jar" and a classifier.
Hence if users declare <dependencies> on them using the <classifier>
only they would be handled by the patch just as already outlined for the
test-jar case.
Benjamin
[0]
http://svn.apache.org/repos/asf/maven/components/branches/maven-2.1.x/maven-artifact/src/main/resources/META-INF/plexus/components.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-4056, please comment
Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:
> Yeah, it sounds right.
OK, so there seem to be no objections to the patch. As such, I will try
to apply it to 2.1.x and 3.x this day or tomorrow.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-4056, please comment
Posted by Brett Porter <br...@apache.org>.
Yeah, it sounds right. The ids should definitely be normalized when
reading them so that matching classifier/extension combos map back to
the same types.
- Brett
On 02/03/2009, at 11:43 AM, Brian E. Fox wrote:
> Seems logical to me. I don't know why there are these special mappings
> in the first place. Sources is the other one that comes to mind... if
> true you should handle that the same.
>
> -----Original Message-----
> From: Benjamin Bentmann [mailto:benjamin.bentmann@udo.edu]
> Sent: Sunday, March 01, 2009 9:11 AM
> To: Maven Developers List
> Subject: MNG-4056, please comment
>
> Hi,
>
> I recently created a patch for MNG-4056 and would appreciate some
> comments whether that's the proper way to address the issue.
>
> In short, this issue is about the subtle difference between
>
> <dependency>
> <groupId>gid</groupId>
> <artifactId>aid</artifactId>
> <version>0.1</version>
> <classifier>tests</classifier>
> </dependency>
>
> and
>
> <dependency>
> <groupId>gid</groupId>
> <artifactId>aid</artifactId>
> <version>0.1</version>
> <type>test-jar</type>
> </dependency>
>
> i.e. <type>test-jar</type> vs. <classifier>tests</classifier>. While
> both declarations work during builds of the consumer project that
> run up
>
> to the "install" phase, only the latter declaration will allow proper
> dependency resolution from the reactor during an earlier lifecycle
> phase
>
> like "package" (see also comments in MNG-2045 [0]).
>
> The cause for this difference is that resolution from the reactor
> matches artifacts by their dependency conflict id which has the form
> gid:aid:type:classifier. For the first dependency declaration above,
> the
>
> type is "jar" which doesn't match the type "test-jar" as used for the
> attached test JAR.
>
> In case matching by dependency conflict id fails, the proposed patch
> falls back to another id I called repository conflict id (well, it
> needed to have a name...). The important difference is that the
> repository conflict id has the form gid:aid:extension:classifier, i.e.
> uses the file extension instead of the type.
>
> The rationale for this approach is the observation that the repository
> layout does not use the artifact type but the file extension to
> distinguish files. In other words, the ids
> gid:aid:test-jar:tests:0.1
> and
> gid:aid:jar:tests:0.1
> get mapped to the same physical file in the repository, namely
> gid/aid/0.1/aid-0.1/aid-0.1-tests.jar
> i.e. there's an aliasing effect in the repository which the patch
> mimics
>
> for dependency resolution from the reactor.
>
> It solves the problem from a user's perspective but I'm not sure
> whether
>
> this kind of artifact identity is clean from a design perspective.
> WDYT?
>
>
> Benjamin
>
>
> [0]
> http://jira.codehaus.org/browse/MNG-2045?focusedCommentId=152064&page=co
> m.atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> tabpanel#action_
> 152064
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: MNG-4056, please comment
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Seems logical to me. I don't know why there are these special mappings
in the first place. Sources is the other one that comes to mind... if
true you should handle that the same.
-----Original Message-----
From: Benjamin Bentmann [mailto:benjamin.bentmann@udo.edu]
Sent: Sunday, March 01, 2009 9:11 AM
To: Maven Developers List
Subject: MNG-4056, please comment
Hi,
I recently created a patch for MNG-4056 and would appreciate some
comments whether that's the proper way to address the issue.
In short, this issue is about the subtle difference between
<dependency>
<groupId>gid</groupId>
<artifactId>aid</artifactId>
<version>0.1</version>
<classifier>tests</classifier>
</dependency>
and
<dependency>
<groupId>gid</groupId>
<artifactId>aid</artifactId>
<version>0.1</version>
<type>test-jar</type>
</dependency>
i.e. <type>test-jar</type> vs. <classifier>tests</classifier>. While
both declarations work during builds of the consumer project that run up
to the "install" phase, only the latter declaration will allow proper
dependency resolution from the reactor during an earlier lifecycle phase
like "package" (see also comments in MNG-2045 [0]).
The cause for this difference is that resolution from the reactor
matches artifacts by their dependency conflict id which has the form
gid:aid:type:classifier. For the first dependency declaration above, the
type is "jar" which doesn't match the type "test-jar" as used for the
attached test JAR.
In case matching by dependency conflict id fails, the proposed patch
falls back to another id I called repository conflict id (well, it
needed to have a name...). The important difference is that the
repository conflict id has the form gid:aid:extension:classifier, i.e.
uses the file extension instead of the type.
The rationale for this approach is the observation that the repository
layout does not use the artifact type but the file extension to
distinguish files. In other words, the ids
gid:aid:test-jar:tests:0.1
and
gid:aid:jar:tests:0.1
get mapped to the same physical file in the repository, namely
gid/aid/0.1/aid-0.1/aid-0.1-tests.jar
i.e. there's an aliasing effect in the repository which the patch mimics
for dependency resolution from the reactor.
It solves the problem from a user's perspective but I'm not sure whether
this kind of artifact identity is clean from a design perspective. WDYT?
Benjamin
[0]
http://jira.codehaus.org/browse/MNG-2045?focusedCommentId=152064&page=co
m.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_
152064
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org