www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@maven.org>
Subject Re: Comments on URI Syntax
Date Sun, 09 Nov 2003 07:10:44 GMT
On Sun, 2003-11-09 at 01:41, Tim Anderson wrote:
> I have a few comments on the proposed URI Syntax, from
> http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax.
> <quote>
>    Compromise URI
>    http://<host>/<project>/<version>/artifact-[<version>;].ext
>    For example
>    http://repo.apache.org/org-apache-ant/1.5.1/ant-1.5.1.jar
>    http://repo.apache.org/org-apache-ant/1.5.1/ant-testutil-1.5.1.jar
>    http://repo.apache.org/org-apache-ant/1.5.1/LICENSE.txt
> </quote>

Having the <version> in the path certainly doesn't hurt readability and
it definitely will make the structure more navigable as it keeps a
massive number of artifacts from piling up in one place. And of course
you have the by product of faster indexing and quicker hits by the file
system and if transfered to another storage mechanism the reduction of
the bit per bucket can only be a good thing. Simple ideas are good ones.
Good idea!


> 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.

> 2. Does '.ext' need to be mandatory?
>    I'm assuming that a project is free to deploy whatever it
>    likes into the repository, not all of which should be forced
>    to have extensions (e.g, Unix shell scripts, README files).

I don't think they need to be, but I haven't thought about that one
much. We have presumed so in Maven because artifacts have generally been
archives but there's no reason there has to be an extension.

> 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.

> 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.


>    . <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>/][<platform>/]<arti
> fact>,

For <organization> I would suggest a <groupId> where most projects would
use their FQDN and split on the dot for directory structure. 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

So my attempt for further refinement would be this:


> with the format of <artifact> determined by the deployment tool.
> For example:
>    http://repo.apache.org/apache/ant/1.5.4/LICENSE.txt
>    http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar
>    http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.zip
> http://repo.apache.org/apache/httpd/2.0.43/binaries/sparc-sun-solaris2.8/htt
> pd-2.0.43-sparc-sun-solaris2.8.tar.gz
>    http://repo.mycompany.com/sun/jndi/jars/jndi-1.2.1.jar
> Regards,
> Tim

Jason van Zyl

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  -- Jacques Ellul, The Technological Society

View raw message