This all sounds fine - I'm still leaning towards webdav (bit
specific, but it will always use that technology anyway) over manage
(too generic a name, xmlrpc is also managing and will likely be at a
different endpoint). But I'm not that fussed.
So the only thing left is the question I mailed separately about
which JIRA issue this belongs in, and when it is scheduled for :)
- Brett
On 31/07/2007, at 10:09 PM, Joakim Erdfelt wrote:
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