> From: Jason van Zyl [mailto:[EMAIL PROTECTED] >
<snip/> > > > 1. This should be written as: > > http://<host>/<project>/<version>/artifact[-<version>].ext > > as the '-' is only required if the version is present. > > I think the version should always be present. People will use the > repository directly and I think that's ok so you if you copy an artifact > somewhere by mistake it is always nice to have as much information as > possible so making the version optional I don't think is a great idea. I think that the artifact naming should be determined by the deployment tool. It might not make sense to include the version in the actual name. E.g, the license files currently stored by maven: http://www.ibiblio.org/maven/commons-dbcp/licenses/license.html With the changes to the URI syntax I'm proposing, using version 1.1 of commons-dbcp as an example, the license would be stored at: http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license.html not: http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license-1.1.html <snip/> > > > 3. <project> is too limiting as it is required to be globally > > unique, resulting in unwieldy names like: > > "jakarta-commons-logging" or "org.apache.jakarta.commons.logging" > > > > I would prefer to see this split into: > > <organisation>/<product> > > where: > > . <organisation> is arbitrary, but globally unique. > > It could be the domain name, e.g "sun.com", the reverse domain > > name e.g "org.apache", or simply the name of the organisation, e.g > > "oracle". > > > > . <project> is the project name, unique within the organisation, > > e.g: "jndi", "ldap", "commons-logging" etc. > > What we've discussed in Maven-land is using something like a groupId > which might look like: org.apache.maven and actually split on the dot to > make a directory. So basically organization by FQDN. Something which > would also make indexing easier in filesystems and I think makes it > easier to navigate by a person. So maven and axion would appear in the repository would have groupIds of "org.apache.maven" and "org.tigris.axion" and appear under "/org/apache/maven/" and "/org/tigris/axion/" respectively? I would have had them under "/org.apache/maven" and "/org.tigris/axion". Assuming that the names apache and tigris are globally unique company names, this could be shortened to "/apache/maven" and "/tigris/axion". This doesn't require any '.' to '/' translation, as is required using the groupId approach. The inputs to an automatic fetch are the same as those a user would input into their browser. Not really fussed either way. <snip/> > > > 4. <artifact> is too limiting as it groups all artifacts for one > > project in a single directory. For projects producing large > > no.s of artifacts, it becomes difficult for users to browse. > > The httpd project for example produces multiple binaries, for > > different platforms (see http://www.apache.org/dist/httpd/) > > The requirement that -<version> is prepended to the artifact > > name also doesn't support language specific requirements. > > > > I would prefer to see this split into: > > [<type>/][<platform>/]<artifact> > > > > where: > > . <type> is optional and arbitrary, determined by the > deployment tool. > > E.g: "jars", "binaries", "docs" etc. > > . <platform> is optional and arbitrary, determined by the deployment > > tool. > > Having the type I think is good and has worked for Maven. > > +1 > > > . <artifact> is determined by the deployment tool, and includes: > > . the artifact name > > . the version (optional) > > . the platform (optional) > > . the extension (optional) > > . the type (optional) > > E.g, "-src", "-bin" etc. > > > > This allows the repository to cater for language-specific deployment > > tools. For java, <artifact> could be: > > <artifact-name>[-<version>][-<type>][.<ext>] > > E.g: > > . LICENSE.txt > > . ant-1.5.1.jar > > . ant-1.5.1-src.zip > > > > For C binaries, <artifact> could be: > > <artifact-name>-<version>-<platform>.<ext> > > E.g: > > . httpd-2.0.43-sparc-sun-solaris2.8.tar.gz > > > > In summary, I think the URI should be of the form: > > > > > http://<host>/<organisation>/<project>/<version>/[<type>/][<platfo rm>/]<arti > fact>, > > For <organization> I would suggest a <groupId> where most projects would > use their FQDN and split on the dot for directory structure. OK, so long as deployment tools don't make the assumption that groupId == FQDN. Using the fully qualified domain name for top-level projects such as maven would result in a redundant directory being created: http://<host>/org/apache/maven/maven/.... which makes it confusing to browse. > Also the > manditory use of a version in the artifact name as even in your example > below the LICENSE.txt could potentially change from one release to > another and you wouldn't want to copy one version over another by > mistake and distribute it. An Unlikely example yes, but possible if the > version is not in the artifact itself. I also think the type should be > required. See previous example on license files. > > So my attempt for further refinement would be this: > > http://<host>/<groupId>/<project>/<version>/<type>/[<platform>/]/<artifact>- <version>[.ext] <type> may not make sense for all repository users, which is why I made it optional. I'm also not convinced that <artifact>-<version>[.ext] is sufficient. It works for most java artifacts, but doesn't translate to other languages: E.g, IIRC shared libraries on solaris (all *nix?) are typically named: lib<artifact-name>.so.<version> -Tim
