Geez. my very first sentence has an error. :-(
There are _3_ split points present in every filename.
ArtifactId|version|classifier|type
There, now I feel better.
- Joakim
Joakim Erdfelt wrote:
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
