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 23:07:06 GMT
In regards to the second idea.

It's two fold.

First part is to split the /repository/ into 
This is to eliminate the guessing, the ambiguity, etc.

Second part is to dive deeper when working with legacy paths to request 
the pom for the same resource path and utilize the information present 
in that pom to better determine the correct artifactId / version that 
the original author intended.

This can be accomplished by simply replacing the extension with .pom and 
fetching that content too.

- Joakim

nicolas de loof wrote:
> The idea of having a set of potential artifactIds is an interesting alternative.
> This might produce more network traffic on proxies, but is the only
> way to ensure the expected artifact requested by maven1 is found in a
> maven2 repo. Maybe a cache could be set to maintain Last recently
> Resolved legacy requests ? Or maybe some more meta-data can be sored
> in DB and attached to the groupId ?
> Having the repository URL splitted into deterministic layouts will not
> solve the Maven1-request-to-maven2-managed-repository issue. What do
> you mean about "Use this along with pom information on the same file
> should clear up any confusion" as to read the expected pom we need the
> artifactId, don't we ?
> About MRM-517, it looks strange that those path are resolved to legacy
> layout as they include more than 3 "/". The legacy layout only applies
> when the path contains 2 "/" (group/types/artifact.type). I don't have
> the source code here to confirm this and look further, and will
> inversitgate this one tomorrow.
> Nico.
> 2007/9/26, Joakim Erdfelt <>:
>> 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:
>> 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

View raw message