archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject Re: [Proposal] Repository Layout Detection/Interaction Changes.
Date Tue, 09 Oct 2007 15:45:23 GMT
Brett Porter wrote:
>
> 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).

The special case work can be accomplished with the proposal.
I don't like it, it screams *hack*, but if it'll get us closer to 1.0 
then so be it.

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

How does the extension affect the breakdown of the version id?

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

We don't have 90% coverage of m1/legacy repos.
When I run through a simple LegacyLayout.toArtifact(path) on the files 
(paths only) present in the 
http://people.apache.org/repo/m1-ibiblio-rsync-repository/ repository, i 
get a ~40% failure rate.

I think I'll add that file listing to the unit tests today and make that 
a unit test.
Must pass with <10% failure rate.

The reworking of the layout routines has allowed for greater flexibility 
along with proper usage by the consumers.

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

The magnitude isn't as large as you think, it's mostly done already.
Just wrapping up the unit testing today.

- Joakim

Mime
View raw message