archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <>
Subject Re: critical issue with 1.0-beta-2 !!!
Date Wed, 26 Sep 2007 14:57:03 GMT
There are 4 split points present in every filename.

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.


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

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 
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 <>:
>> I've created for this and
>> attached a patch.
>> 2007/9/25, nicolas de loof <>:
>>> 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
  Open Source Software (OSS) Developer

View raw message