Mailing-List: contact archiva-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: archiva-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46FA733F.60509@erdfelt.com>
Date: Wed, 26 Sep 2007 07:57:03 -0700
From: Joakim Erdfelt <joakim@erdfelt.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070501)
MIME-Version: 1.0
To: archiva-dev@maven.apache.org
Subject: Re: critical issue with 1.0-beta-2 !!!
References: <4c39e3030709250819v741fe27do5b2b843a5ff36ac8@mail.gmail.com>
	 <4c39e3030709250844s30ada12bx91aef38edddd4b66@mail.gmail.com>
 <4c39e3030709260431w6bec8ebdlfaf6e7378ac05355@mail.gmail.com>
In-Reply-To: <4c39e3030709260431w6bec8ebdlfaf6e7378ac05355@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

There are 4 split points present in every filename.
ArtifactId|version|classifier|type

Determining the artifactId and version is easy enough with maven 2 
default layout, as the artifactId and version are present in the full 
path to the artifact.

example:
http://repo1.maven.org/maven2/groovy/groovy-1.0-jsr/06/groovy-1.0-jsr-06.jar

But working with maven 1 requests, this is *much* more ambiguous and non 
deterministic.

Some file / layout problems found in Jira.

MRM-519 [Fail to resolve artifactId for libs that contain versionKeyword 
in artifactId, like "maven-test-plugin"]
This comes from the fact that you are likely requesting the 
maven-test-plugin from using a maven 1 (legacy) layout format from a 
repository on archiva that is configured as maven 2 (default) layout 
storage.
This translation cannot work 100% of the time.

MRM-432 [Proxy Connectors are unable to download artifacts with alpha 
numerical version numbers]
This one is about oddball version ids such as found in 
ganymed-ssh-build210.jar, comm-3.0-u1.jar, and 
ejb-3.0-public_review.jar.  These version specs are difficult to 
identify as part of the version, and not the classifier.

MRM-517 [Some maven 2 requests are treated as maven 1 requests]
This is due to the duality of request handling in the present 
/repository/ URL.

Some Ideas:

One idea I had last night was to rework the filename to artifact object 
for Legacy layout to be a list of potential Artifact object's, but this 
is really only relevant when working with the translation between an 
incoming request at maven 1 (legacy) to a maven 2 (default) resource. 
(this flow applies for internal repository translation, and also 
proxying of content from remote repos at different layout formats)

Another idea is to split the /repository/ url into two, using the 
/repository/legacy/ or /repository/default/ identifiers to clearly 
identify what your intention is.  Use this along with pom information on 
the same file (when a legacy request occurs) should clear up any confusion.

- Joakim


nicolas de loof wrote:
> As Joakim noticed, my quick-fix patch breaks many testcases. It also
> doesn't covers some valid cases, like the use of classifiers with "-"
> tokens.
>
> Still looking for a working artifactId detection strategy...
>
> I myself sometime hardly discover the artifactId. Lets look at groovy :
> "groovy-1.0-jsr-06"
>
> Is this "groovy" artifact with version "1.0-jsr-06",
> or (as it is in repo) "groovy-1.0-jsr" version "06" ?
> I'm not sure there is any fully deterministic way to solve this.
>
> Maybe the only way to solve this is to have RepositoryLayoutUtils
> manage an "exception" list to it's default token based discovery. And
> this would require some more UI to configure it...
>
> Nico.
>
> 2007/9/25, nicolas de loof <nicolas.deloof@gmail.com>:
>   
>> I've created http://jira.codehaus.org/browse/MRM-519 for this and
>> attached a patch.
>>
>> 2007/9/25, nicolas de loof <nicolas.deloof@gmail.com>:
>>     
>>> I just installed beta-2 in replacement to my corporate repo.
>>> I may had better tested it before :-(
>>>
>>> requesting using maven1 an artifact with "-" in artifactID fails :
>>>
>>> request for "maven/plugins/maven-test-plugin-1.8.2.jar"
>>> in logs :
>>> <proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
>>> does not exist
>>>
>>> The versionUtil.versionPatterns seems to grab too much tags as possible version.
>>>
>>> I've patched it locally to remove "test[_.0-9]*" as possible version
>>> pattern. Could we enhance this artifactId detection by ensuring ALL
>>> tokens considered as version are valid versionElements ?
>>>
>>> Something like this :
>>> [- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
>>>
>>> In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
>>> valid versionElement, "test" and "plugin" may have been added to the
>>> artifactId
>>>
>>>       
>
>   


-- 
- Joakim Erdfelt
  joakim@erdfelt.com
  Open Source Software (OSS) Developer