archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: What is Archiva.NEXT ?
Date Tue, 31 Jul 2007 03:02:16 GMT

On 31/07/2007, at 12:43 PM, Joakim Erdfelt wrote:

> I'm tired.
> I'm tired of the confusion.
> I'm tired of the lack of decision.

k, I have a proposal at the end, just working through the details.

>
> The ability to serve the repository information to multiple clients  
> is exactly the reason for splitting this logic out.

ok, I missed that. Thanks for clarifying.

> The 4 clients.
> * Apache Maven 2
> * Apache Maven 1.1
> * Apache Maven 1.0
> * Apache Ivy

understood (though I still don't see the distinction between maven 1  
versions). I'm also wondering if there is something we have to do now  
to support Ivy or if it "just works". Given that Ivy sully supports  
m2 repos now, I think this is a nice to have.

>
> The 4 types of data that is fetched from the repository.
> * Artifacts
> * Versioned Metadata.xml
> * Project (unversioned) Metadata.xml
> * Checksum files

Not all types have these things, though - metadata is only applicable  
to Maven 2, and Ivy (and other repositories) likely have other files.

>
> Since we hit collisions on the auto-discovery technique for maven 1  
> to maven 2 requests (ie: legacy vs default), the need to have a  
> different 'view' to the repository is crucial.  (one such collision  
> in naming is when a metadata.xml file is requested and the path is  
> detected as a maven 1 resource.  there are more, but addressing  
> each 'special case' will just result in a piece of code horribly  
> convoluted and ultimately doomed to maintenance hell)

I thought it was maintainable for the set of clients listed so far,  
but if we look to support others than I can see how that might be the  
case, so fair enough.

>
> Now instead of talking about layouts (legacy vs default) and paths  
> as the means to an end, the idea of access or client identifiers in  
> the URL was discussed.  /get/${accessor_id}/${repo_id}/${resource}
>
> I'm about to rip it apart and implement it as proposed, as I want  
> to see it work, and no one has yet to propose a different viable  
> solution to the issue.

I still don't like the format.

My proposal is this:
1) Please use /repository and /webdav instead of /get and /put.
2) please let a repository specify a default accessor_id so that the  
repository need not be so long
3) please saw repo_id and accessor_id

I think that is the best alternative here. What do others think  - am  
I on another planet? :)

>
> This support is important in archiva, and we are getting close to a  
> 1.0 release.

That's why I'm being such a nuisance :)

- Brett

Mime
View raw message