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
"/repository/<repo_id>/[a-zA-Z0-9].*"
3) establish a way to view the repository differently.
The pattern for this is "/repository/<repo_id>/\[[a-zA-Z0-9-]*\]/.*"
Example:
/repository/corporate/[maven2]/org/apache/ant/1.7.0/ant-1.7.0.jar
/repository/corporate/[maven1]/org.apache.ant/jars/ant-1.7.0.jar
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 :)
Aaah?
Aaah!
Aaah?
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
