In regards to the second idea.
It's two fold.
First part is to split the /repository/ into
/repository/${repoid}/${layout}/${resource}
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 <[EMAIL PROTECTED]>:
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
