You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Tim Anderson <tm...@netspace.net.au> on 2003/11/10 08:31:22 UTC
[proposal] java artifact specifier v0.1
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/ReadMsg?listName=repository@apache.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
licenses:
http://repo.apache.org/apache/ant/1.5.4/licenses/LICENSE.txt
PGP keys:
http://repo.apache.org/apache/ant/1.5.4/KEYS
Re: [proposal] java artifact specifier v0.1
Posted by Michal Maczka <mm...@interia.pl>.
Tim Anderson wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Michal Maczka wrote:
>>
>>
>>
>>>IMHO "type" directory should be mandatory
>>>
>>>
>>+1
>>
>>
>
>-1 for reasons outlined previously in
>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
>gNo=312
>
>
You mean your example with index.html?
I am repating that for me this file is not an artifacts.
We can imagine that we will have repositories accssible via ftp://
file:// scp:// , cvs://
In such repositiries "index.html" is rather useless
My intutitive definition of artifacts is:
a) Artifact is a file which you would like to see in any of those type
of repositories mentioned above
b) Artifact is a file which is in some sense intresting for
computers/tools (and possibly for humans)
index.html is not such file.
So I am still +1 for directories per type
regards
Michal
RE: [proposal] java artifact specifier v0.1
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Michal Maczka wrote:
>
> > IMHO "type" directory should be mandatory
>
>
> +1
-1 for reasons outlined previously in
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
gNo=312
>
> >
> >
> > 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.
> >
> > 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" | ...
>
>
>
> I'm not keen on the notion of a static type enumeration and
> corresponding plural form. This sort of information can be easily
> expressed in a meta descriptor at the level of a group - .e.g.
> ".group". A .group file could include the mapping of a type to its
> plural form within the scope of the group which would significantly
> improve the machine friendliness of the repository model. You can apply
> the same principal to distinguish and qualify other level in the
> repository - e.g. .type qualifying a directory as a type directory.
>
> Stephen.
I'm hoping we can produce a set of specifications without resorting
to meta-data. Meta data is great for writing generic tools, but
we don't have enough requirements from other languages to
agree on what is required. I suspect attempting to get
any sort of concensus would paralyze this effort.
-Tim
Re: [proposal] java artifact specifier v0.1
Posted by Stephen McConnell <mc...@apache.org>.
Michal Maczka wrote:
> IMHO "type" directory should be mandatory
+1
>
>
> 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.
>
> 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" | ...
I'm not keen on the notion of a static type enumeration and
corresponding plural form. This sort of information can be easily
expressed in a meta descriptor at the level of a group - .e.g.
".group". A .group file could include the mapping of a type to its
plural form within the scope of the group which would significantly
improve the machine friendliness of the repository model. You can apply
the same principal to distinguish and qualify other level in the
repository - e.g. .type qualifying a directory as a type directory.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: [proposal] java artifact specifier v0.1
Posted by Michal Maczka <mm...@interia.pl>.
[..]
>>
>>
>
>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/ReadMsg?listName=repository@apache.org&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
Re: [proposal] java artifact specifier v0.1
Posted by Michal Maczka <mm...@interia.pl>.
>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
>
>
>
Surly for for some reasons it would be better to have ( I am even
prefering this style):
jars/foo-1.0-beta1.jar
javadocs/foo-1.0-beta1.jar
sources/foo-1.0-beta1.jar
java-sources/foo-1.0-beta1.jar
("stype" is always skipped)
But there are some reason why it's not the ultimate solution.
Michal
RE: [proposal] java artifact specifier v0.1
Posted by Tim Anderson <tm...@netspace.net.au>.
See inline.
> From: Michal Maczka [mailto:mmaczka@interia.pl]
>
> 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/ReadMsg?listName=repository@ap
> 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/ReadMsg?listName=repository@apache.org&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
RE: [proposal] java artifact specifier v0.1
Posted by di...@multitask.com.au.
"Noel J. Bergman" <no...@devtech.com> wrote on 11/11/2003 07:33:53 AM:
> > Why "source" and not "sources"?
> > Plural form of "type" should be used consistently for naming
directories.
>
> That's a bit nit-picky. Let's agree on the structure, and then worry
about
> spelling. :-)
>
> > I am still against versionless filenames:
>
> Why? KEYS, for example, need not have a version. Probably SHOULD not
have
> a version, in fact. The latest version should be used. In most other
Keys may indeed have a version. KEYS may not always be cumulative. And if
it had a version number, wouldn't need to be.
[snip]
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
RE: [proposal] java artifact specifier v0.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Why "source" and not "sources"?
> Plural form of "type" should be used consistently for naming directories.
That's a bit nit-picky. Let's agree on the structure, and then worry about
spelling. :-)
> I am still against versionless filenames:
Why? KEYS, for example, need not have a version. Probably SHOULD not have
a version, in fact. The latest version should be used. In most other
cases, I agree that the artifact should have a version because otherwise it
is lost when downloaded.
> For sake of consistency there should be no exceptions
I agree with the Best Practice, but I don't believe that we need a mandate.
Mandates should only be used where necessary for function/inter-operability.
> I am not sure if we need a separate directory per version.
As I mentioned a few minutes ago, a per-version directory helps to organize
the collected downloads for a particular release. This can be very helpful
for the people NOT using an automated tool to do the download.
Mind you, my proposal carries forward the current reliance on symlinks, and
then uses it to allow multiple organizations of the same data, thus making
it easier to find and acquire what one is looking for.
--- Noel
Re: [proposal] java artifact specifier v0.1
Posted by Michal Maczka <mm...@interia.pl>.
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/ReadMsg?listName=repository@apache.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.
And why type and what you've called "stype" are expressing the same
thing but named differently?
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
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.
>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.
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".
Michal
RE: [proposal] java artifact specifier v0.1
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Fri, 14 Nov 2003 08:16 pm, Michal Maczka wrote:
> > >The only purpose of "type" in maven is to indicate how it is
> processed by
> > > the runtime. (ie plugins get installed, jars get added to
> classpath etc).
> > > It does not even specify that extension as there is a M-to-M
> between type
> > > and extension. ie.
> >
> > I don't agree that this is the only purpose of "type".
> >
> > I think it's reasonable to have "type" directory as this can separate
> > artifact produced by various tools. ... I would like to have an
> exclusivity
> > for adding artifacts to directories like (jars/sources/distribution).
> > But I could accept if somebody (some tool)
> > is keeping its files in sibling directories. Also some "exotic"
> > artifacts are making the repository harder to navigate.
>
> Sounds reasonable. But maybe the term "type" is not the best term
> for this as
> it does not designate a "type" but a arbitary subdivision of
> space based on
> usage patterns. Not sure what a better term would be?
>
I thought of using "category" but opted for "type" simply because
it is shorter.
-Tim
Re: [proposal] java artifact specifier v0.1
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Nov 2003 08:16 pm, Michal Maczka wrote:
> >The only purpose of "type" in maven is to indicate how it is processed by
> > the runtime. (ie plugins get installed, jars get added to classpath etc).
> > It does not even specify that extension as there is a M-to-M between type
> > and extension. ie.
>
> I don't agree that this is the only purpose of "type".
>
> I think it's reasonable to have "type" directory as this can separate
> artifact produced by various tools. ... I would like to have an exclusivity
> for adding artifacts to directories like (jars/sources/distribution).
> But I could accept if somebody (some tool)
> is keeping its files in sibling directories. Also some "exotic"
> artifacts are making the repository harder to navigate.
Sounds reasonable. But maybe the term "type" is not the best term for this as
it does not designate a "type" but a arbitary subdivision of space based on
usage patterns. Not sure what a better term would be?
--
Cheers,
Peter Donald
"The true measure of a man is how he treats
someone who can do him absolutely no good."
- Samuel Johnson (1709-1784)
Re: [proposal] java artifact specifier v0.1
Posted by Michal Maczka <mm...@interia.pl>.
Peter Donald wrote:
>On Thu, 13 Nov 2003 09:04 pm, Michal Maczka wrote:
>
>
>>Yes - you are right they don't differ in this purpose.
>>But it doesn't mean that one of them is not need. I think that
>>repository is "easily navigated"
>>when both "groupId" and "type" directories co-exits.
>>
>>
>
>I guess what I saying is why not collapse both of them into one given that
>there is no distinction in purpose or in implementation.
>
>The only purpose of "type" in maven is to indicate how it is processed by the
>runtime. (ie plugins get installed, jars get added to classpath etc). It does
>not even specify that extension as there is a M-to-M between type and
>extension. ie.
>
>
>
I don't agree that this is the only purpose of "type".
I think it's reasonable to have "type" directory as this can separate
artifact produced by various tools.
For example Ant is not build with Maven (and never will be) but we can
still add Maven's POM for Ant to the repository.
The POM can be also added for Struts, Xerces etc. If some other tools
like Gump need their own meta data
they should be free to add it to the repository. But I question the
fact if such files should be mixed with "distributions".
I don't like an idea of putting everything into one huge bag. If I were
a Struts developer I would hate
if somebody puts some strange artifacts into the directory which I
maintain. I would like to have an exclusivity
for adding artifacts to directories like (jars/sources/distribution).
But I could accept if somebody (some tool)
is keeping its files in sibling directories. Also some "exotic"
artifacts are making the repository harder to navigate.
Why to mix them with "importand" artifacts?
Michal
Re: [proposal] java artifact specifier v0.1
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 13 Nov 2003 09:04 pm, Michal Maczka wrote:
> Yes - you are right they don't differ in this purpose.
> But it doesn't mean that one of them is not need. I think that
> repository is "easily navigated"
> when both "groupId" and "type" directories co-exits.
I guess what I saying is why not collapse both of them into one given that
there is no distinction in purpose or in implementation.
The only purpose of "type" in maven is to indicate how it is processed by the
runtime. (ie plugins get installed, jars get added to classpath etc). It does
not even specify that extension as there is a M-to-M between type and
extension. ie.
X.jar --> jar, ejb
distribution --> .tar.gz, .tar.bz2
--
Cheers,
Peter Donald
"Copy from one, it's plagiarism; copy
from two, it's research."
- Wilson Mizner (1876-1933)
Re: [proposal] java artifact specifier v0.1
Posted by Michal Maczka <mm...@interia.pl>.
peter@realityforge.org wrote:
>Hi,
>
>From: "Tim Anderson" <tm...@netspace.net.au>
>
>
>>'type' is there to logically group artifacts, to aid users browsing
>>the repository. For products with many artifacts, this makes navigating
>>the repository easier.
>>
>>
>
>So the sole purpose of this is to make navigation easier? Isn't that what
>the groupID is meant to be used for? How does type/groupID differ in their
>purposes?
>
>
>
>
Yes - you are right they don't differ in this purpose.
But it doesn't mean that one of them is not need. I think that
repository is "easily navigated"
when both "groupId" and "type" directories co-exits.
(replaying to you other email)
>"type" seems to be a rather artificial component. There should be
> no artefacts
> with the same name but different types thus no conflicts if they
> are in the
> same directory.
>
> ie Why not have
>
> http://repo.apache.org/apache/ant/1.5.4/ant-1.5.4.jar
> http://repo.apache.org/apache/ant/1.5.4/ant-1.5.4.jar.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-optional-1.5.4.jar
> http://repo.apache.org/apache/ant/1.5.4/ant-optional-1.5.4.jar.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.tar.gz
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.tar.gz.asc
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.zip
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.zip.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.tar.gz
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.tar.gz.asc
> http://repo.apache.org/apache/ant/1.5.4/LICENSE-1.5.4.txt
> http://repo.apache.org/apache/ant/1.5.4/KEYS-1.5.4
>
> Also "stype" seems like another artificial distinction. Is not
> two artefacts
> with different "stype"s just two different artefacts.
>
You intuition is correct. But as I understand - we are trying to apply more analytical approach and
split strings like ant-src-1.5.4.zip.md5 into smaller pieces so for example nobody uses
http://repo.apache.org/apache/ant/1.5.4/src-ant-1.5.4.tar.gz.asc
http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip
at the same time,
Nobody in fact uses - http://repo.apache.org/apache/ant/1.5.4/src-ant-1.5.4.tar.gz.asc
(at least very rarely) but we just want to describe more precisely what
ant-bin-1.5.4.zip means and differentiate it from (e.g.) bin-ant-1.5.4.zip.
So it's like we want to formalize some intuitions and pratices.
regards
Michal
Re: [proposal] java artifact specifier v0.1
Posted by Ben Walding <be...@walding.com>.
1. Magical chopping of the groupId into parts and then arbitrarily
dropping the first one, most of the time.
I'm in favour of just using groupId over organisation + id.
And I don't particularly like dropping org / com, the DNS is a good
way to enforce uniqueness - let's use it.
I see little advantage in not mandating that groupId be globally
unique - the reverse domain name. The number of crappy little components
(eg "ftp") that I've had to magically name to something else on ibiblio
is just frustrating. This will only get worse as you put more crap into
the repository. And there will be crap... lots of it... eg. sourceforge
currently has 70,925 projects...
-------------
2. Pluralisation of types
Historically within Maven we have had the jars directory and little else
(poms/ licenses are only infrequently used - and typically not by tools)
When we specify a dependency, it looks something like this
<dependency>
<id>commons-lang</id>
<type>jar</type>
<version>1.0.3</version>
</dependency>
This is all well and good for things which are pluralised by adding
"s"... not so good otherwise.
Hence I'd prefer if we didn't go with pluralised names for the type.
It'll just require another mapping array in every tool which says...
jar => jars, binary => binaries, source => source
as opposed to just using type
jar => jar, binary => binary, source => source
How can I justify this? What is the type of artifacts in this folder?
They are of type jar. They are not of type jars.
This is more of a nuisance than a real problem however.
It's good to see progress being made.
Cheers,
Ben
RE: [proposal] java artifact specifier v0.1
Posted by Tim Anderson <tm...@netspace.net.au>.
Take a look at the proposals:
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts
Hopefully it will be clear.
-Tim
> -----Original Message-----
> From: peter@realityforge.org [mailto:peter@realityforge.org]
> Sent: Thursday, 13 November 2003 1:39 PM
> To: repository@apache.org
> Subject: Re: [proposal] java artifact specifier v0.1
>
>
> Hi,
>
> From: "Tim Anderson" <tm...@netspace.net.au>
> > 'type' is there to logically group artifacts, to aid users browsing
> > the repository. For products with many artifacts, this makes navigating
> > the repository easier.
>
> So the sole purpose of this is to make navigation easier? Isn't that what
> the groupID is meant to be used for? How does type/groupID differ in their
> purposes?
>
>
Re: [proposal] java artifact specifier v0.1
Posted by pe...@realityforge.org.
Hi,
From: "Tim Anderson" <tm...@netspace.net.au>
> 'type' is there to logically group artifacts, to aid users browsing
> the repository. For products with many artifacts, this makes navigating
> the repository easier.
So the sole purpose of this is to make navigation easier? Isn't that what
the groupID is meant to be used for? How does type/groupID differ in their
purposes?
RE: [proposal] java artifact specifier v0.1
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
>
> On Mon, 10 Nov 2003 06:31 pm, Tim Anderson wrote:
> > 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" | ...
>
> "type" seems to be a rather artificial component. There should be
> no artefacts
> with the same name but different types thus no conflicts if they
> are in the
> same directory.
>
> ie Why not have
>
> http://repo.apache.org/apache/ant/1.5.4/ant-1.5.4.jar
> http://repo.apache.org/apache/ant/1.5.4/ant-1.5.4.jar.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-optional-1.5.4.jar
> http://repo.apache.org/apache/ant/1.5.4/ant-optional-1.5.4.jar.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.tar.gz
> http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.tar.gz.asc
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.zip
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.zip.md5
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.tar.gz
> http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.tar.gz.asc
> http://repo.apache.org/apache/ant/1.5.4/LICENSE-1.5.4.txt
> http://repo.apache.org/apache/ant/1.5.4/KEYS-1.5.4
>
> Also "stype" seems like another artificial distinction. Is not
> two artefacts
> with different "stype"s just two different artefacts.
>
> ie
>
> ant-src-1.5.4.tar.gz ==> artifact-name == ant-src
> ant-bin-1.5.4.tar.gz ==> artifact-name == ant-bin
>
> It seems that is just adding extra distinctions that are not
> really needed.
> And I can't see any benefit of these extra distinctions.
>
'type' is there to logically group artifacts, to aid users browsing
the repository. For products with many artifacts, this makes navigating
the repository easier.
The values of both 'type' and 'stype' are arbitrary - the suggested
values for the java artifact specifier try to follow conventions
used at apache.
-Tim
Re: [proposal] java artifact specifier v0.1
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 10 Nov 2003 06:31 pm, Tim Anderson wrote:
> 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" | ...
"type" seems to be a rather artificial component. There should be no artefacts
with the same name but different types thus no conflicts if they are in the
same directory.
ie Why not have
http://repo.apache.org/apache/ant/1.5.4/ant-1.5.4.jar
http://repo.apache.org/apache/ant/1.5.4/ant-1.5.4.jar.md5
http://repo.apache.org/apache/ant/1.5.4/ant-optional-1.5.4.jar
http://repo.apache.org/apache/ant/1.5.4/ant-optional-1.5.4.jar.md5
http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip
http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.zip.md5
http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.tar.gz
http://repo.apache.org/apache/ant/1.5.4/ant-bin-1.5.4.tar.gz.asc
http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.zip
http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.zip.md5
http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.tar.gz
http://repo.apache.org/apache/ant/1.5.4/ant-src-1.5.4.tar.gz.asc
http://repo.apache.org/apache/ant/1.5.4/LICENSE-1.5.4.txt
http://repo.apache.org/apache/ant/1.5.4/KEYS-1.5.4
Also "stype" seems like another artificial distinction. Is not two artefacts
with different "stype"s just two different artefacts.
ie
ant-src-1.5.4.tar.gz ==> artifact-name == ant-src
ant-bin-1.5.4.tar.gz ==> artifact-name == ant-bin
It seems that is just adding extra distinctions that are not really needed.
And I can't see any benefit of these extra distinctions.
--
Cheers,
Peter Donald
*-------------------------------------------*
| "A handful of sand is an anthology of the |
| universe." -Albert Einstein |
*-------------------------------------------*