archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <>
Subject Re: What is Archiva.NEXT ?
Date Tue, 31 Jul 2007 12:09:53 GMT
Brett Porter wrote:
> 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.
That was my attempt at a disclaimer.  ;-)
>> * Apache Maven 2
>> * Apache Maven 1.1
>> * Apache Maven 1.0
>> * Apache Ivy
> The 4 clients.
> 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.

Maven 2, Maven 1.1, and Ivy work right now.   They all support the maven 
2 default layout fine.
With minor differences in patterns when it comes to the metadata.xml and 
checksum files.

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

True, but keep in mind that all archiva has to work with is a repo_id 
and a requested_resource_path.
Going from those limited pieces of information to an actual resource is 
the tricky part.
Does the client want an artifact? or a metadata.xml? or a checksum file?

>> 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? :)

I think I follow you.

How about this ...

1) the current /repository servlet gets split into 2 servlets.
    /repository/ becomes the dynamic GET servlet.
    /manage/ becomes the original webdav servlet.

2) each repository can have an default_accessor_id assigned to it.
     The pattern for use as default accessor is 

3) establish a way to view the repository differently.
     The pattern for this is "/repository/<repo_id>/\[[a-zA-Z0-9-]*\]/.*"

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


- Joakim Erdfelt
  Open Source Software (OSS) Developer

View raw message