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 <[EMAIL PROTECTED]>:
I've created http://jira.codehaus.org/browse/MRM-519 for this and
attached a patch.
2007/9/25, nicolas de loof <[EMAIL PROTECTED]>:
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
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
