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/09 07:41:48 UTC
Comments on URI Syntax
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>
1. This should be written as:
http://<host>/<project>/<version>/artifact[-<version>].ext
as the '-' is only required if the version is present.
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).
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.
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.
. <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>,
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
RE: Comments on URI Syntax
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Was the bottom of this message eaten again? I've tried twice now but in
> the response I get back from the list my little URL example isn't
> present. Is it showing up in the messages you guys are getting?
Did you check the archives to see what is recorded there?
http://nagoya.apache.org/eyebrowse/BrowseList?listName=repository@apache.org
&by=author&from=88965&to=88965&first=1&count=16
--- Noel
Re: Comments on URI Syntax
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2003-11-09 at 02:23, Jason van Zyl wrote:
> On Sun, 2003-11-09 at 02:10, Jason van Zyl wrote:
>
> > 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
> > required.
> >
> > So my attempt for further refinement would be this:
>
> Sorry about that, not sure how the bottom end got lost there ... anyway
Was the bottom of this message eaten again? I've tried twice now but in
the response I get back from the list my little URL example isn't
present. Is it showing up in the messages you guys are getting?
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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
Re: Comments on URI Syntax
Posted by peter royal <pr...@apache.org>.
On Nov 9, 2003, at 6:48 AM, Tim Anderson wrote:
> 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".
I'm with your on not having a root "/org" directory.
For a user navigating, that only knows the company name, they don't
have to worry about what TLD it exists in.
-pete
Re: Comments on URI Syntax
Posted by Stephen McConnell <mc...@apache.org>.
dion@multitask.com.au wrote:
>>>From the requirements at
>>http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
>>"ASF Repository shall ... allow browsing and downloading of artifacts by
>>humans via normal
>>web browser".
>>Requiring a version to be part of the artifact file name when the
>>
>>
>artifact
>
>
>>is only useful
>>to end users (e.g README), reduces clarity.
>>
>>
>But it does increase usability sometimes.
>
>README for which version?
>
Good point!
Is not a README a feature of an artifact?
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Tim Anderson wrote:
>
> >>From: Stephen McConnell [mailto:mcconnell@apache.org]
> >>
> >>Woops - see small correction in line.
> >>
> >>Stephen McConnell wrote:
> >>
> >>
> >>
> >>>Tim Anderson wrote:
> >>>
> >>>
> >>>
> >>>>>By implication - the README is not an artifact but a feature of a
> >>>>>version.
> >>>>>Is that a reasonable conclusion?
> >>>>>Stephen.
> >>>>>
> >>>>>
> >>>>>
> >>>>Why make the distinction? I view everything a project deploys as an
> >>>>artifact. Some artifacts will only be useful to end users (e.g,
> >>>>README, LICENSE.txt etc), others will be useful to tools.
> >>>>
> >>>>
> >>>>
> >>>Because there is difference between aggregation of files of a
> >>>partiular type as distinct from files that describe a particular typed
> >>>file instance. I view the "artifact" as the principal file held in a
> >>>directory qualifed by a type (e.g. the jar file in a jars directory),
> >>>and that other resources such as READMEs, LICENSEs, MD5s, etc. are
> >>>examples of data that describe features of specific things such as a
> >>>group, version, artifact, etc.
> >>>
> >>>Why make the distinction? When I look at the available artifacts in a
> >>>/jars/ directory I will present these as an list of artifacts. A user
> >>>may select to view the properties/features of one of these items.
> >>>Using the name of an artifact - I can locate additional information
> >>>about the artifact such as the MD5 signature, maybe the license or
> >>>some dependency information - providing there is a convention that is
> >>>predictable. I.e. I need a mechanism to locate information about a
> >>>particular artifact - e.g.
> >>>
> >>>
> >>I left out the all important principal artifact.
> >>
> >> <artifact-path>.<type> <--------- the principal artifact (e.g.
> >>jars/fred.jar)
> >> <artifact-path>.<something> <------ some metadata
> >> <artifact-path>.<something-else> <-- more meta data
> >> <artifact-path>.MD5 <--------------- artifact signature
> >> <artifact-path>.README <------------ readme about the artifact
> >>
> >>The important thing is the recognition of the difference between a file
> >>that *is* the artifact as distinct from a file that *describes*
> >>an artifact.
> >>
> >>Stephen.
> >>
> >>
> >>
> >>> <artifact-path>.<something>
> >>> <artifact-path>.<something-else>
> >>> <artifact-path>.MD5
> >>> <artifact-path>.README
> >>>
> >>>Etc.
> >>>
> >>>Stephen.
> >>>
> >>>
> >
> >File aggregation is important to tools, less so for end-users.
> >The MD5 is just another artifact - its up to the tools
> >to determine its association with other artifacts.
> >
>
> If the MD5 is just another artifact then it would belong under
> something like:
>
> http://www.ibiblio.org/maven/ant/md5s/some-artifact-name.md5
No it wouldn't. The <type> in the URI is optional
(see
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
gNo=266).
If there is a logical grouping of artifacts, they can go under
the same base path.
-Tim
Re: Comments on URI Syntax
Posted by Stephen McConnell <mc...@apache.org>.
Tim Anderson wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Woops - see small correction in line.
>>
>>Stephen McConnell wrote:
>>
>>
>>
>>>Tim Anderson wrote:
>>>
>>>
>>>
>>>>>By implication - the README is not an artifact but a feature of a
>>>>>version.
>>>>>Is that a reasonable conclusion?
>>>>>Stephen.
>>>>>
>>>>>
>>>>>
>>>>Why make the distinction? I view everything a project deploys as an
>>>>artifact. Some artifacts will only be useful to end users (e.g,
>>>>README, LICENSE.txt etc), others will be useful to tools.
>>>>
>>>>
>>>>
>>>Because there is difference between aggregation of files of a
>>>partiular type as distinct from files that describe a particular typed
>>>file instance. I view the "artifact" as the principal file held in a
>>>directory qualifed by a type (e.g. the jar file in a jars directory),
>>>and that other resources such as READMEs, LICENSEs, MD5s, etc. are
>>>examples of data that describe features of specific things such as a
>>>group, version, artifact, etc.
>>>
>>>Why make the distinction? When I look at the available artifacts in a
>>>/jars/ directory I will present these as an list of artifacts. A user
>>>may select to view the properties/features of one of these items.
>>>Using the name of an artifact - I can locate additional information
>>>about the artifact such as the MD5 signature, maybe the license or
>>>some dependency information - providing there is a convention that is
>>>predictable. I.e. I need a mechanism to locate information about a
>>>particular artifact - e.g.
>>>
>>>
>>I left out the all important principal artifact.
>>
>> <artifact-path>.<type> <--------- the principal artifact (e.g.
>>jars/fred.jar)
>> <artifact-path>.<something> <------ some metadata
>> <artifact-path>.<something-else> <-- more meta data
>> <artifact-path>.MD5 <--------------- artifact signature
>> <artifact-path>.README <------------ readme about the artifact
>>
>>The important thing is the recognition of the difference between a file
>>that *is* the artifact as distinct from a file that *describes*
>>an artifact.
>>
>>Stephen.
>>
>>
>>
>>> <artifact-path>.<something>
>>> <artifact-path>.<something-else>
>>> <artifact-path>.MD5
>>> <artifact-path>.README
>>>
>>>Etc.
>>>
>>>Stephen.
>>>
>>>
>
>File aggregation is important to tools, less so for end-users.
>The MD5 is just another artifact - its up to the tools
>to determine its association with other artifacts.
>
If the MD5 is just another artifact then it would belong under
something like:
http://www.ibiblio.org/maven/ant/md5s/some-artifact-name.md5
But that does not make sence (or types don't make sence). The
fact is that there really is a differnce between <path> and
<path>.<meta> providing that there that is a recognition in the
base repository schema that these are two different things.
That recognition (as a part of the schema) is very important for
the attribution of information that would be used in the next
level up - i.e. that leyer on which meta data is accesses to
in order to manage an anttribute.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Woops - see small correction in line.
>
> Stephen McConnell wrote:
>
> >
> >
> > Tim Anderson wrote:
> >
> >>> By implication - the README is not an artifact but a feature of a
> >>> version.
> >>> Is that a reasonable conclusion?
> >>> Stephen.
> >>>
> >>
> >>
> >> Why make the distinction? I view everything a project deploys as an
> >> artifact. Some artifacts will only be useful to end users (e.g,
> >> README, LICENSE.txt etc), others will be useful to tools.
> >>
> >
> > Because there is difference between aggregation of files of a
> > partiular type as distinct from files that describe a particular typed
> > file instance. I view the "artifact" as the principal file held in a
> > directory qualifed by a type (e.g. the jar file in a jars directory),
> > and that other resources such as READMEs, LICENSEs, MD5s, etc. are
> > examples of data that describe features of specific things such as a
> > group, version, artifact, etc.
> >
> > Why make the distinction? When I look at the available artifacts in a
> > /jars/ directory I will present these as an list of artifacts. A user
> > may select to view the properties/features of one of these items.
> > Using the name of an artifact - I can locate additional information
> > about the artifact such as the MD5 signature, maybe the license or
> > some dependency information - providing there is a convention that is
> > predictable. I.e. I need a mechanism to locate information about a
> > particular artifact - e.g.
>
>
> I left out the all important principal artifact.
>
> <artifact-path>.<type> <--------- the principal artifact (e.g.
> jars/fred.jar)
> <artifact-path>.<something> <------ some metadata
> <artifact-path>.<something-else> <-- more meta data
> <artifact-path>.MD5 <--------------- artifact signature
> <artifact-path>.README <------------ readme about the artifact
>
> The important thing is the recognition of the difference between a file
> that *is* the artifact as distinct from a file that *describes*
> an artifact.
>
> Stephen.
>
> >
> >
> > <artifact-path>.<something>
> > <artifact-path>.<something-else>
> > <artifact-path>.MD5
> > <artifact-path>.README
> >
> > Etc.
> >
> > Stephen.
File aggregation is important to tools, less so for end-users.
The MD5 is just another artifact - its up to the tools
to determine its association with other artifacts.
-Tim
Re: Comments on URI Syntax
Posted by Stephen McConnell <mc...@apache.org>.
Woops - see small correction in line.
Stephen McConnell wrote:
>
>
> Tim Anderson wrote:
>
>>> By implication - the README is not an artifact but a feature of a
>>> version.
>>> Is that a reasonable conclusion?
>>> Stephen.
>>>
>>
>>
>> Why make the distinction? I view everything a project deploys as an
>> artifact. Some artifacts will only be useful to end users (e.g,
>> README, LICENSE.txt etc), others will be useful to tools.
>>
>
> Because there is difference between aggregation of files of a
> partiular type as distinct from files that describe a particular typed
> file instance. I view the "artifact" as the principal file held in a
> directory qualifed by a type (e.g. the jar file in a jars directory),
> and that other resources such as READMEs, LICENSEs, MD5s, etc. are
> examples of data that describe features of specific things such as a
> group, version, artifact, etc.
>
> Why make the distinction? When I look at the available artifacts in a
> /jars/ directory I will present these as an list of artifacts. A user
> may select to view the properties/features of one of these items.
> Using the name of an artifact - I can locate additional information
> about the artifact such as the MD5 signature, maybe the license or
> some dependency information - providing there is a convention that is
> predictable. I.e. I need a mechanism to locate information about a
> particular artifact - e.g.
I left out the all important principal artifact.
<artifact-path>.<type> <--------- the principal artifact (e.g.
jars/fred.jar)
<artifact-path>.<something> <------ some metadata
<artifact-path>.<something-else> <-- more meta data
<artifact-path>.MD5 <--------------- artifact signature
<artifact-path>.README <------------ readme about the artifact
The important thing is the recognition of the difference between a file
that *is* the artifact as distinct from a file that *describes* an artifact.
Stephen.
>
>
> <artifact-path>.<something>
> <artifact-path>.<something-else>
> <artifact-path>.MD5
> <artifact-path>.README
>
> Etc.
>
> Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: Comments on URI Syntax
Posted by Stephen McConnell <mc...@apache.org>.
Tim Anderson wrote:
>>By implication - the README is not an artifact but a feature of a version.
>>Is that a reasonable conclusion?
>>Stephen.
>>
>>
>
>Why make the distinction? I view everything a project deploys as an
>artifact. Some artifacts will only be useful to end users (e.g,
>README, LICENSE.txt etc), others will be useful to tools.
>
Because there is difference between aggregation of files of a partiular
type as distinct from files that describe a particular typed file
instance. I view the "artifact" as the principal file held in a
directory qualifed by a type (e.g. the jar file in a jars directory),
and that other resources such as READMEs, LICENSEs, MD5s, etc. are
examples of data that describe features of specific things such as a
group, version, artifact, etc.
Why make the distinction? When I look at the available artifacts in a
/jars/ directory I will present these as an list of artifacts. A user
may select to view the properties/features of one of these items. Using
the name of an artifact - I can locate additional information about the
artifact such as the MD5 signature, maybe the license or some dependency
information - providing there is a convention that is predictable. I.e.
I need a mechanism to locate information about a particular artifact - e.g.
<artifact-path>.<something>
<artifact-path>.<something-else>
<artifact-path>.MD5
<artifact-path>.README
Etc.
Stephen.
>
>-Tim
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
>> Tim Anderson wrote:
>
>>>From: dion@multitask.com.au [mailto:dion@multitask.com.au]
>>>
>>>
>>>
>>>>>From the requirements at
>>>>http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
>>>>"ASF Repository shall ... allow browsing and downloading of artifacts by
>>>>humans via normal
>>>>web browser".
>>>>Requiring a version to be part of the artifact file name when the
>>>>artifact is only useful to end users (e.g README), reduces clarity.
>>>>
>>>But it does increase usability sometimes.
>>>
>>>README for which version?
>>
>>
>>An example:
>> http://repo.apache.org/apache/commons-dbcp/1.1/README
>>
>>The README is for version 1.1 of commons-dbcp.
>>
>By implication - the README is not an artifact but a feature of a version.
>Is that a reasonable conclusion?
>Stephen.
Why make the distinction? I view everything a project deploys as an
artifact.
Some artifacts will only be useful to end users (e.g, README, LICENSE.txt
etc),
others will be useful to tools.
-Tim
index.html (was Comments on URI Syntax
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> http://repo.apache.org/apache/commons-logging/1.0.3/index.html
>
> Clearly, this is only useful to users browsing the repository,
> and therefore makes no sense to include the version information.
On index.html, wouldn't we discourage the use of this? Wouldn't we want the
HTTP server to do a directory listing, so publishers wouldn't have to update
it every time? Also, if we are to allow/support automatic remote publishing,
not having to lock/update an index.html would be a bonus.
Parsing HTML (simple or fancy) to find "links that are children" is pretty
trivial, so it probably wouldn't matter (to clients who are going to have to
do this anyway) but it probably matters to publishers.
regards
Adam
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
OK, suppose a project deploys an index.html to
the repository, which contains the release notes for the release, e.g.
http://repo.apache.org/apache/commons-logging/1.0.3/index.html
Clearly, this is only useful to users browsing the repository,
and therefore makes no sense to include the version information.
-Tim
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Monday, 10 November 2003 11:35 AM
> To: repository@apache.org
> Subject: Re: Comments on URI Syntax
>
>
> Stephen McConnell <mc...@apache.org> wrote on 10/11/2003 10:58:09 AM:
>
> > By implication - the README is not an artifact but a feature of a
> version.
> > Is that a reasonable conclusion?
>
> I'd question the value of distributing a README as a single file.
>
> In the maven world, we have a type called 'distribution', which
> contains a
> README, jar, source etc.
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
> Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
>
>
>
>
Re: Comments on URI Syntax
Posted by di...@multitask.com.au.
Stephen McConnell <mc...@apache.org> wrote on 10/11/2003 10:58:09 AM:
> By implication - the README is not an artifact but a feature of a
version.
> Is that a reasonable conclusion?
I'd question the value of distributing a README as a single file.
In the maven world, we have a type called 'distribution', which contains a
README, jar, source etc.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: Comments on URI Syntax
Posted by Stephen McConnell <mc...@apache.org>.
Tim Anderson wrote:
>>From: dion@multitask.com.au [mailto:dion@multitask.com.au]
>>
>>
>>
>>>>From the requirements at
>>>http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
>>>"ASF Repository shall ... allow browsing and downloading of artifacts by
>>>humans via normal
>>>web browser".
>>>Requiring a version to be part of the artifact file name when the
>>>
>>>
>>artifact
>>
>>
>>>is only useful
>>>to end users (e.g README), reduces clarity.
>>>
>>>
>>But it does increase usability sometimes.
>>
>>README for which version?
>>
>>
>
>An example:
> http://repo.apache.org/apache/commons-dbcp/1.1/README
>
>The README is for version 1.1 of commons-dbcp.
>
By implication - the README is not an artifact but a feature of a version.
Is that a reasonable conclusion?
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
RE: Comments on URI Syntax
Posted by di...@multitask.com.au.
"Tim Anderson" <tm...@netspace.net.au> wrote on 10/11/2003 10:53:47 AM:
> > From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> >
> > > From the requirements at
> > >
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
> > > "ASF Repository shall ... allow browsing and downloading of
artifacts by
> > > humans via normal
> > > web browser".
> > > Requiring a version to be part of the artifact file name when the
> > artifact
> > > is only useful
> > > to end users (e.g README), reduces clarity.
> > But it does increase usability sometimes.
> >
> > README for which version?
>
> An example:
> http://repo.apache.org/apache/commons-dbcp/1.1/README
>
> The README is for version 1.1 of commons-dbcp.
That's easy enough to work out from the URL, what happens after I've
downloaded it?
In the case of a README, you'd hope it contained some version info
anyways, but for other stuff?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
>
> > From the requirements at
> > http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
> > "ASF Repository shall ... allow browsing and downloading of artifacts by
> > humans via normal
> > web browser".
> > Requiring a version to be part of the artifact file name when the
> artifact
> > is only useful
> > to end users (e.g README), reduces clarity.
> But it does increase usability sometimes.
>
> README for which version?
An example:
http://repo.apache.org/apache/commons-dbcp/1.1/README
The README is for version 1.1 of commons-dbcp.
-Tim
RE: Comments on URI Syntax
Posted by di...@multitask.com.au.
> From the requirements at
> http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
> "ASF Repository shall ... allow browsing and downloading of artifacts by
> humans via normal
> web browser".
> Requiring a version to be part of the artifact file name when the
artifact
> is only useful
> to end users (e.g README), reduces clarity.
But it does increase usability sometimes.
README for which version?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Michal Maczka [mailto:mmaczka@interia.pl]
>
> [snip]
> > 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
> >
>
> In case of the majority of artifacts version name should be a part of
> artifact file name.
> I might agree that
> http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license.html
> is acceptable but for a sake of consistency - we should rather use
> http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license-1.1.html
>
>
> Note that artifacts like
>
> http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license-1.1.html
>
> or
>
> http://repo.apache.org/apache/stsruts/1.1/tlds/struts-tiles.1.1.tld
>
> are almost always no important for humans.
>
>
> Michal
>
>From the requirements at
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements:
"ASF Repository shall ... allow browsing and downloading of artifacts by
humans via normal
web browser".
Requiring a version to be part of the artifact file name when the artifact
is only useful
to end users (e.g README), reduces clarity.
-Tim
RE: Comments on URI Syntax
Posted by Michal Maczka <mm...@interia.pl>.
[snip]
> 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
>
In case of the majority of artifacts version name should be a part of
artifact file name.
I might agree that
http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license.html
is acceptable but for a sake of consistency - we should rather use
http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license-1.1.html
Note that artifacts like
http://repo.apache.org/apache/commons-dbcp/1.1/licenses/license-1.1.html
or
http://repo.apache.org/apache/stsruts/1.1/tlds/struts-tiles.1.1.tld
are almost always no important for humans.
Michal
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
>
<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
RE: Comments on URI Syntax
Posted by Jason van Zyl <jv...@maven.org>.
On Sun, 2003-11-09 at 02:22, Noel J. Bergman wrote:
> Jason,
>
> I think that Tim's ideas were pretty well-thought out and reflect a workable
> consensus. The changes you are making to his ideas, if I read the
> correctly, are to mandate a couple of things that he did not rule out, but
> permitted to remain optional. Having them as optional does not strike me as
> a problem.
>
> Best practices can always suggest that optional elements be used, and we'll
> discover in practice how broadly the rule(s) should apply.
>
> We should make sure that folks like William Rowe and others who have
> commented on the repository structure lately take a look at, and provide
> feedback on, Tim's layout.
If someone else wants to act as secretary that's cool but I wanted to
try and collect the ideas expressed so far in a small document. I'm not
a huge fan of the wiki. If someone else has started some coherent
documentation I won't step on anyone's toes but I'll help codify any
existing docs there are.
> --- Noel
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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
RE: Comments on URI Syntax
Posted by Tim Anderson <tm...@netspace.net.au>.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
gNo=266
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Sunday, 9 November 2003 7:28 PM
> To: repository@apache.org
> Subject: RE: Comments on URI Syntax
>
>
> Where is "Tim's Layout"?
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
> Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
>
>
> "Noel J. Bergman" <no...@devtech.com> wrote on 09/11/2003 06:22:51 PM:
>
> > Jason,
> >
> > I think that Tim's ideas were pretty well-thought out and reflect a
> workable
> > consensus. The changes you are making to his ideas, if I read the
> > correctly, are to mandate a couple of things that he did not rule out,
> but
> > permitted to remain optional. Having them as optional does not strike
> me as
> > a problem.
> >
> > Best practices can always suggest that optional elements be used, and
> we'll
> > discover in practice how broadly the rule(s) should apply.
> >
> > We should make sure that folks like William Rowe and others who have
> > commented on the repository structure lately take a look at, and provide
> > feedback on, Tim's layout.
> >
> > --- Noel
> >
>
>
RE: Comments on URI Syntax
Posted by di...@multitask.com.au.
Where is "Tim's Layout"?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
"Noel J. Bergman" <no...@devtech.com> wrote on 09/11/2003 06:22:51 PM:
> Jason,
>
> I think that Tim's ideas were pretty well-thought out and reflect a
workable
> consensus. The changes you are making to his ideas, if I read the
> correctly, are to mandate a couple of things that he did not rule out,
but
> permitted to remain optional. Having them as optional does not strike
me as
> a problem.
>
> Best practices can always suggest that optional elements be used, and
we'll
> discover in practice how broadly the rule(s) should apply.
>
> We should make sure that folks like William Rowe and others who have
> commented on the repository structure lately take a look at, and provide
> feedback on, Tim's layout.
>
> --- Noel
>
RE: Comments on URI Syntax
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
I think that Tim's ideas were pretty well-thought out and reflect a workable
consensus. The changes you are making to his ideas, if I read the
correctly, are to mandate a couple of things that he did not rule out, but
permitted to remain optional. Having them as optional does not strike me as
a problem.
Best practices can always suggest that optional elements be used, and we'll
discover in practice how broadly the rule(s) should apply.
We should make sure that folks like William Rowe and others who have
commented on the repository structure lately take a look at, and provide
feedback on, Tim's layout.
--- Noel
Re: Comments on URI Syntax
Posted by Jason van Zyl <jv...@maven.org>.
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
> 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.
+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>/][<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
required.
So my attempt for further refinement would be this:
http://<host>/<groupId>/<project>/<version>/<type>/[<platform>/]/<artifact>-<version>[.ext]
> 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
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
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