See inline.

> From: Michal Maczka [mailto:[EMAIL PROTECTED]
>
> Tim Anderson wrote:
>
> >Overview
> >--------
> >
> >The aim of this proposal is to specify the URI syntax for artifacts
> >for java-based projects. It extends the URI syntax proposal:
> >http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
> ache.org&ms
> >gNo=308
> >
> >Java project artifacts include, but are not limited to:
> >   jars, wars, rars, tlds, source and binary distributions, and
> >   licenses.
> >
> >URI Components
> >--------------
> >
> >An absolute repository URI is written as follows:
> >
> >  repository-uri = access-specifier "/" product-specifier "/"
> >                   artifact-specifier
> >
> >For java artifacts, artifact-specifier is:
> >
> >  artifact-specifier = [type "/"] artifact
> >  type = "jars" | "wars" | "rars" | "tlds" | "binaries" | "source"
> >         | "licenses" | ...
> >  artifact = artifact-name ["-" version] ["-" stype][.ext]
> >  artifact-name = *pchar
> >  stype = "bin" | "src"
> >  ext = "jar" | "war" | "rar" | "tld" | "tar.gz" | "zip" | ...
> >
> >
>
> >Checksums & PGP signatures
> >--------------------------
> >
> >All artifacts may have an associated md5 checksum, of the form:
> >
> >  artifact-specifier ".md5"
> >
> >or a PGP signatures, of the form:
> >
> >  artifact-specifier ".asc"
> >
> >Examples
> >--------
> >
> >jars:
> >  http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar
> >  http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.md5
> >  http://repo.apache.org/apache/ant/1.5.4/jars/ant-optional-1.5.4.jar
> >  http://repo.apache.org/apache/ant/1.5.4/jars/ant-optional-1.5.4.jar.md5
> >
> >binaries:
> >  http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.zip
> >  http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.zip.md5
> >  http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.tar.gz
> >
> http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-bin.tar.gz.asc
> >
> >source:
> >  http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.zip
> >  http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.zip.md5
> >  http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.tar.gz
> >  http://repo.apache.org/apache/ant/1.5.4/source/ant-1.5.4-src.tar.gz.asc
> >
> >
> >
>
> Why "source" and not "sources"?
> Plural form of  "type" should be used consistently for naming directories.

I was basing this on existing conventions, e.g:
http://www.apache.org/dist/ant/

>
>
> And why type and what you've called  "stype" are expressing the same
> thing but named differently?

stype == 'type short name'. For java artifacts, it currently
only applies to binary and source distributions.

>
> Why not
>
>   http://repo.apache.org/apache/ant/1.5.4/sources/ant-1.5.4-source.zip
>     or
>   http://repo.apache.org/apache/ant/1.5.4/srcs/ant-1.5.4-src.zip
>
>    And
>
>   http://repo.apache.org/apache/ant/1.5.4/binaries/ant-1.5.4-binary.zip
>
>      or
>   http://repo.apache.org/apache/ant/1.5.4/bins/ant-1.5.4-bin.zip
>
>
> >licenses:
> >  http://repo.apache.org/apache/ant/1.5.4/licenses/LICENSE.txt
> >
> >
> >
> >
> >
> I am still against versionless filenames:
> For sake of consistency there should be no exceptions from the rule that
> every artifact in repository has version in it's filename.
>
> licenses:
>   http://repo.apache.org/apache/ant/1.5.4/licenses/LICENSE-1.5.4.txt
>
>

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

>
> This results in duplications of  version string in the URL.
> I am not sure if we need a separate directory per version.
>
> We can have:
> http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar
>                                   1.6.0/jars/ant-1.6.0.jar
>
> Or
> http://repo.apache.org/apache/ant/jars/ant-1.5.4.jar
>                                        ant-1.6.0.jar
>
>
> 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.

>
>
>
> >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.
. mandating that all artifacts should follow one naming convention
  is doomed to fail.

>
>
>
> My proposition is:
>
>
>   repository-uri = access-specifier "/" product-specifier "/"
>                    artifact-specifier
>
> For java artifacts, artifact-specifier is:
>
>   artifact-specifier = {plural form of type} "/" artifact
>
>   type = "jar" | "war" | "rar" | "tld" | "binary" | "source"
>          | "license" | ...
>
>   {plural form of type} = "jars" | "wars" | "rars" | "tlds" |
> "binaries" | "source"
>          | "licenses" | ...
>   artifact = artifact-name "-" version ["-" type][.ext][.metatype]
>   artifact-name = *pchar
>   ext = "jar" | "war" | "rar" | "tld" | "tar.gz" | "zip" | ...
>   metatype= "md5" | "sha" | "asc"
>
>
> In my version "type" is used two times in the URL  - Directly and
> in plural form.
> I have no idea how to formaly denote the plural form of "type".
>

You've still got some magic happening there, for non-binary and
non-source artifacts. Under your proposal, a naive tool might
expect version 1.0-beta1 of foo.jar to appear as:
  jars/foo-1.0-beta1-jar.jar

-Tim


Reply via email to