Return-Path: 
 <dev-return-88547-apmail-maven-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-dev-archive@www.apache.org
Received: (qmail 53498 invoked from network); 2 Mar 2009 00:49:21 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Mar 2009 00:49:21 -0000
Received: (qmail 69722 invoked by uid 500); 2 Mar 2009 00:49:18 -0000
Delivered-To: apmail-maven-dev-archive@maven.apache.org
Received: (qmail 69094 invoked by uid 500); 2 Mar 2009 00:49:17 -0000
Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@maven.apache.org>
List-Help: <mailto:dev-help@maven.apache.org>
List-Post: <mailto:dev@maven.apache.org>
List-Id: "Maven Developers List" <dev.maven.apache.org>
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Delivered-To: mailing list dev@maven.apache.org
Received: (qmail 69073 invoked by uid 99); 2 Mar 2009 00:49:17 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Mar 2009 16:49:17 -0800
X-ASF-Spam-Status: No, hits=-1.0 required=10.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of brianf@reply.infinity.nu
 designates 205.210.42.66 as permitted sender)
Received: from [205.210.42.66] (HELO mailout.easydns.com) (205.210.42.66)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Mar 2009 00:49:07 +0000
Received: from localhost (localhost [127.0.0.1])
	by mailout.easydns.com (Postfix) with ESMTP id 09DA1481EE
	for <dev@maven.apache.org>; Sun,  1 Mar 2009 19:47:45 -0500 (EST)
Received: from mailout.easydns.com ([127.0.0.1])
	by localhost (mailout.easydns.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ebqkt-0pdOEI for <dev@maven.apache.org>;
	Sun,  1 Mar 2009 19:47:45 -0500 (EST)
Received: from intrepid.infinity.nu (c-98-229-225-70.hsd1.nh.comcast.net
 [98.229.225.70])
	by mailout.easydns.com (Postfix) with ESMTP id DD1C748087
	for <dev@maven.apache.org>; Sun,  1 Mar 2009 19:47:44 -0500 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: MNG-4056, please comment
Date: Sun, 1 Mar 2009 19:43:54 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <2BABBE7D2A66E04DB8A66A527D29927E53C035@intrepid.infinity.nu>
In-Reply-To: <49AA9760.9060504@udo.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: MNG-4056, please comment
Thread-Index: Acmad3c7aaV09UxnRo2Lax17ubTRWAAWG1uQ
References: <49AA9760.9060504@udo.edu>
From: "Brian E. Fox" <brianf@reply.infinity.nu>
To: "Maven Developers List" <dev@maven.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

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]=20
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=20
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=20
both declarations work during builds of the consumer project that run up

to the "install" phase, only the latter declaration will allow proper=20
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=20
matches artifacts by their dependency conflict id which has the form=20
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=20
attached test JAR.

In case matching by dependency conflict id fails, the proposed patch=20
falls back to another id I called repository conflict id (well, it=20
needed to have a name...). The important difference is that the=20
repository conflict id has the form gid:aid:extension:classifier, i.e.=20
uses the file extension instead of the type.

The rationale for this approach is the observation that the repository=20
layout does not use the artifact type but the file extension to=20
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]=20
http://jira.codehaus.org/browse/MNG-2045?focusedCommentId=3D152064&page=3D=
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