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
