RE: Comments on URI Syntax
From: Stephen McConnell [mailto:[EMAIL PROTECTED] Tim Anderson wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: Comments on URI Syntax
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:[EMAIL PROTECTED]
Re: Comments on URI Syntax
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:[EMAIL PROTECTED]
RE: Comments on URI Syntax
Tim Anderson [EMAIL PROTECTED] wrote on 10/11/2003 10:53:47 AM: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Stephen McConnell [EMAIL PROTECTED] 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
Tim Anderson wrote: From: Stephen McConnell [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Re: Comments on URI Syntax
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
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 [EMAIL PROTECTED] 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
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=266 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, 9 November 2003 7:28 PM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
RE: Comments on URI Syntax
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Tim Anderson wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
