On 09/10/2007, at 4:30 PM, Joakim Erdfelt wrote:
I think you are missing the core point of the proposal.
(Is nicolas the only one that understands the difficulty?)
No, I get it. I've been there before, several times, remember :)
Using *just* the path information, how do you get from a maven 1
request to an artifact reference?
(groupId, artifactId, version, type)
ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
maven/jars/maven-test-plugin-1.8.2.jar
org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar
These are some examples of the problems that arise.
Using that magic regex that you mentioned (which we use in archiva
too!) we get a 1 to many split from path to reference.
(using "|" syntax for examples of references below groupId|
artifactId|version|type)
ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
becomes one of the following
ch.ethz.ganymed|ganymed|ssh2-build210|jar
ch.ethz.ganymed|ganymed-ssh2|build210|jar
exactly - that's why I suggested some special cases needed to be
listed (dom4j is a common one too).
maven/jars/maven-test-plugin-1.8.2.jar
becomes one of the following
maven|maven|test-plugin-1.8.2|jar
maven|maven-test-plugin|1.8.2|jar
seems like a bug, that should be deterministic through the filename
extension
org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar
becomes one of the following
org.apache.geronimo.specs|geronimo|ejb_2.1_spec-1.0.1|jar
org.apache.geronimo.specs|geronimo-ejb|2.1_spec-1.0.1|jar
org.apache.geronimo.specs|geronimo-ejb_2.1|spec-1.0.1|jar
org.apache.geronimo.specs|geronimo-ejb_2.1_spec|1.0.1|jar
If the current regex picks this as version - 1.0.1, then that is
correct and we can keep using it. If not, maybe we need to change it.
The process to get from maven 1 legacy request to a reference is
not possible 100% of the time.
Yes, that's what I said too.
Any for the record, there is no code in maven 1 or maven 2 that
does this (take a path and get an artifact reference), I've looked
dozens of times, it just doesn't exist.
As the author of said code, I can categorically confirm it doesn't
exist :) That's why I wrote it in the mrm converter (which is now in
the bidirectional repository layout).
The initial proposal was to eliminate this 1 to many problem by
reading the pom file for the information regarding the groupId /
artifactId / version, but that isn't a valid solution when working
with content that needs to be proxied.
Right, and it's not practical in general - so what is the current
status? The proposal is too complicated a solution - I would rather
we get it to work for 90% of the artifacts, special case the rest,
and be done with it. If we really, really find we need to have it
100% deterministic with special cases, then I'd prefer we go back to
adding alternate views on the repository.
But in either case, I think this can be in post-1.0. It's getting way
too late for changes of the magnitude you are proposing.
- Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
