[..]
While it may work for java, it doesn't work for all artifacts.
E.g:
. index.html - a project may choose to deploy this to aid users browsing
the repository.
index.html is not an artifact for me.
That's the part of the web site. And websites and repositories can surly share the same structure and coexists together.
. there is no generic naming convention which will allow a tool to parse the version information from the artifact name. E.g. libfoo.so.1.1 - version appears after the extension.
See (*) below
Both versions of URLs are equally good for tools. As for me the second version is more "human friendly" as it's shorter and repository will be faster to browse.
This doesn't scale for projects which have many versions and produce huge numbers of artifacts. Take a look at the httpd archives, and tell me thats ideal for users browsing the repository: http://archive.apache.org/dist/httpd/binaries
Its far easier if everything is grouped under a version.
OK. I am ready to agree with directory per version.
http://repo.apache.org/apache/ant/1.5.4/KEYS
IMHO "type" directory should be mandatory
We should always use: http://repo.apache.org/apache/ant/1.5.4/keys/KEYS-1.5.4
More rules and exceptions will make entire process harder from point of view of tools.
As stated in the URI Syntax document: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&ms gNo=308
"Projects should be able to deploy arbitrary artifacts to the repository, whether they be for end-users, or meta-data (e.g, maven's project.xml). Tools should ignore any artifact they don't understand"
So:
. if an artifact doesn't follow a naming convention a tool recognises,
it should skip it.
(*) Don't sure if I follow.
Aren't we in the first place trying to find one way mapping between some metadata {version, type, artifactId, groupId, organization} and URL.
We are adressing here just two issues
1) What kind of metadata we need for each artifact
2)Where artifact with known metadata should be located in the repository so it can be:
a) uploaded to repository
b) downloaded from repository
Reverse process : URL to metadata mapping is not interesting for us.
It's clear that if we will have well defined mapping between metadata and URL reverse mapping will be also doable.
So "recognision of artifactas" is not an issue for me.
We are going to HTTP Server for repositories. HTTP doesn't support directory listings so I don't known
where those URLs which you want to parse can come from.
Michal
