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 > > > 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 > >
