RE: Use of '/' in ???-specifier's
From: Stephen McConnell [mailto:[EMAIL PROTECTED] Nick Chalko wrote: Tim Anderson wrote: For advocates of URI parsing, what problems are you trying to solve? * Discovery of what is available * Repository exploring. * Auto cleanup of repositories. The URI spec is too loose. I completely agree. But I just want to add that all I want is either (a) a simple structural spec that does not imply more the 20 mins of concentration, or (b) something auto-explanitory ... a.k.a. server side meta (which acording to me is in scope relative to the objective of qualifying and differentiating organization, artifact, version and all of the other semantics that are currently being generalized. Today - we are not in the 20 min spectrum. Stephen. I would dispute (a), but I'll admit I'm biased. The proposals are public and can be edited and improved by anyone. If you feel there are changes that can be made to improve readability, go ahead - I claim no ownership - much of the content has been distilled from earlier discussions and current ASF practices. As for (b), put forward a proposal. -Tim
Re: Use of '/' in ???-specifier's
Nick Chalko wrote: Tim Anderson wrote: For advocates of URI parsing, what problems are you trying to solve? * Discovery of what is available * Repository exploring. * Auto cleanup of repositories. The URI spec is too loose. I completely agree. But I just want to add that all I want is either (a) a simple structural spec that does not imply more the 20 mins of concentration, or (b) something auto-explanitory ... a.k.a. server side meta (which acording to me is in scope relative to the objective of qualifying and differentiating organization, artifact, version and all of the other semantics that are currently being generalized. Today - we are not in the 20 min spectrum. Stephen. As far as I can tell these are legal http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar We really need to harden the URI spec a little and the / is a good start. R, Nick -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
Re: Use of '/' in ???-specifier's
Here is my 20 second URI http://host/[rootdir]/Orginzation/Product/version/type-specfiic-Artifact one dir each for Org, Prod, and Ver. After that is dependent on the kind of Product. ie the java-artifact-spec. So lets do a 20 sec java artifact spec Stephen McConnell wrote: Nick Chalko wrote: Tim Anderson wrote: For advocates of URI parsing, what problems are you trying to solve? * Discovery of what is available * Repository exploring. * Auto cleanup of repositories. The URI spec is too loose. I completely agree. But I just want to add that all I want is either (a) a simple structural spec that does not imply more the 20 mins of concentration, or (b) something auto-explanitory ... a.k.a. server side meta (which acording to me is in scope relative to the objective of qualifying and differentiating organization, artifact, version and all of the other semantics that are currently being generalized. Today - we are not in the 20 min spectrum. Stephen. As far as I can tell these are legal http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar We really need to harden the URI spec a little and the / is a good start. R, Nick
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: For advocates of URI parsing, what problems are you trying to solve? * Discovery of what is available * Repository exploring. * Auto cleanup of repositories. The URI spec is too loose. As far as I can tell these are legal http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar We really need to harden the URI spec a little and the / is a good start. R, Nick
RE: Use of '/' in ???-specifier's
From: Nick Chalko [mailto:[EMAIL PROTECTED] Tim Anderson wrote: For advocates of URI parsing, what problems are you trying to solve? * Discovery of what is available * Repository exploring. * Auto cleanup of repositories. The URI spec is too loose. As far as I can tell these are legal http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar We really need to harden the URI spec a little and the / is a good start. The above a legal for the URI Syntax proposal [1], but illegal according to the common build version [2] and java artifact specifiers [3]. Tools based on [2] [3] should ignore them. Is it simply a matter of restricting organisation back to a single path segment? This would allow product-specifier to be determined by parsers. Note that this was the original approach, but some people expressed a desire to be able to break down the hierarchy using reverse-FQDNs. As for auto cleanup, this is supported in part by: . version-specifier in [1] All repository URIs must include a version in the path. This: . ensures all artifacts for a particular version are grouped together . simplifies archival of artifacts for a particular version . interim-build in [2] This assigns timestamps for interim builds (nightly, snapshot etc) The repository would have to limit version naming schemes to numeric schemes to support auto cleanup fully, which is too restrictive IMO. -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Proposals [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier [3] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar We really need to harden the URI spec a little and the / is a good start. I missed that the jars or type dir was required. what about, http://repo.apache.org/1/2/3/4/5/6/7/8/pgp/KEYS http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/pgp/KEYS I suppose this is the version named Alpha of the alpha/alpha project. Or is it the alpha release of the version named alpha of the project named alpha or.. These are silly examples, but lets try to prevent at least some of them. The above a legal for the URI Syntax proposal [1], but illegal according to the common build version [2] and java artifact specifiers [3]. Tools based on [2] [3] should ignore them. Is it simply a matter of restricting organisation back to a single path segment? This would allow product-specifier to be determined by parsers. Yes that is the start, make org and product un ambigous is a really good start. Note that this was the original approach, but some people expressed a desire to be able to break down the hierarchy using reverse-FQDNs. I still think reverse-FQDN is a good idea but for parsability I would use . not /
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: From: Nick Chalko [mailto:[EMAIL PROTECTED] Tim Anderson wrote: http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/alpha.jar http://repo.apache.org/1/2/3/4/5/6/7/8/9.jar We really need to harden the URI spec a little and the / is a good start. I missed that the jars or type dir was required. what about, http://repo.apache.org/1/2/3/4/5/6/7/8/pgp/KEYS http://repo.apache.org/alpha/alpha/alpha/alpha/alpha/pgp/KEYS I suppose this is the version named Alpha of the alpha/alpha project. Or is it the alpha release of the version named alpha of the project named alpha or.. These are silly examples, but lets try to prevent at least some of them. OK. If the organisation is limited back to a single path segment, and assuming the repository is rooted at http://repo.apache.org, then the above would be invalid as the: . first 2 path segments are the organisation and project . 3rd path segment is the version (limited to 1 segment as it doesn't meet the criteria for interim builds [1]) . last 2 path segments are the key-artifact artifact-specifier [2] So above would be http://repo.apache.org/alpha.alpha/alpha.alpha/alpha/pgp/KEYS is valid, still silly but easy to tell the org, product and version. -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier [2] Not in wiki yet: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]ms gNo=423
RE: Use of '/' in ???-specifier's
Not a criticism, but I'd prefer to know the requirements, before writing the tools. As far as I can tell, maven doesn't do URI parsing. I don't know a lot about Gump, but if it wants to pull down the newest versions of jars, it can via the latest version tag [1]. Avalon adds meta-data, which is supported through the statement in [2]: 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. -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?action=editid=ASFRepository/Co mmonBuildVersionSpecifier [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 November 2003 5:59 AM To: [EMAIL PROTECTED] Subject: Re: Use of '/' in ???-specifier's Tim Anderson wrote: For advocates of URI parsing, what problems are you trying to solve? This is a simple matter of practicality. We've agreed to delay metadata so we can get a nice/simple repository structure w/o all the differences of opinion that metadata might introduce. We basically want to take existing repository structures (Maven's, Avalon's, Gump's, etc.) and formalize them to promote consistency/re-use. We need a repository that is practical at this level, and practical includes tooling/scripting remote/local clients. Non-parsable URIs (from a loose spec) mean an unreadable repository entries, so it is impractical without metadata. We need parsable URIs so we can have the repository by it's own metadata. I see your reply to Nick references additional specification. I wonder if they just need to merge those into the full lspecification. At this stage of development tight is far better than loose. IMHO, we can make this repository as strict as we like to start with. We need a tight prototypical repository, so we can build a repository and exercise it with tools by hand. We can't keep going back and forth in the theoretical, we need a concrete reference, we need practical experience. regards, Adam
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: Not a criticism, but I'd prefer to know the requirements, before writing the tools. Here is a user story. point a tool at the http://repo.apache.org and have it display what is available This is much easier to do if we can tell the version from the product from the orginzation. R, Nick
Re: Use of '/' in ???-specifier's
Not a criticism, but I'd prefer to know the requirements, before writing the tools. I know, I've been a huge advocate of that, but I'm starting to worry we are in analysis paralysis. Logical URIs are so virtual it is easy to miss practical implications. As such, I'd like to test the theory against the tool implementation in my head. That said, we need to revisit requirements, especially the tooling aspect of that. As Nick said having a tool know/display/process what is in a remote repostiory w/o metadata is my goal. As far as I can tell, maven doesn't do URI parsing. I don't know a lot about Gump, but if it wants to pull down the newest versions of jars, it can via the latest version tag [1]. Gump (like Maven) has metadata also, so could ask for a certain version of something. That said, we are talking about client side metadata with all of these, not in repository metadata. As such, this information is not in the repostory (per se) and so **not available to repository tools**. This is the key point. FWIIW: I *hate* maintaining version information in metadata (in CVS or not) 'cos I think it leads to stale links, and to too much duplication. I think I've said this (once or twice ;-) before though. BTW: I'd like the repository to work independent of client metadata, so we have a consistent repository however tools use it. Maybe we'll have a metadata.xml per directory that we can all agree upon, and extend, but that isn't what we have here and now. Avalon adds meta-data, which is supported through the statement in [2]: 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. Yup, but I'd like to see some cross-project-type tools possible. I'd like tools to be able to work against all types of artefacts, built by Maven, by Gump, by whomever. regards Adam
RE: Use of '/' in ???-specifier's
From: Nick Chalko [mailto:[EMAIL PROTECTED] Noel J. Bergman wrote: Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. The semantic information is there in the URL, org. project. version, artifact type, name, release type etc. People WILL try to parse it. I think it would be a Good Idea to make it easy to parse at least the major pieces into discrete chunks. Assuming most people will simply replace / with - or _ the issue is not one off URL length or URL readability, it seems to be mostly about the browseablity of of directories. In other words have all the apache projects under the apache dir, or under subdirs of apache. I think the convience of knowing exactly where org, project, and version start and stop is worth the cost to browseablity. The proposals aim to structure the repository such that: 1. artifacts can easily be located by users 2. artifacts can easily be located by tools For [2], the intention is that a maven-like approach will be used for artifact resolution i.e, the user specifies enough criteria to enable a tool to unambigously locate an artifact. This approach doesn't require artifact URIs to be parsed. For advocates of URI parsing, what problems are you trying to solve? -Tim
Re: Use of '/' in ???-specifier's
Noel J. Bergman wrote: Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. The semantic information is there in the URL, org. project. version, artifact type, name, release type etc. People WILL try to parse it. I think it would be a Good Idea to make it easy to parse at least the major pieces into discrete chunks. Assuming most people will simply replace / with - or _ the issue is not one off URL length or URL readability, it seems to be mostly about the browseablity of of directories. In other words have all the apache projects under the apache dir, or under subdirs of apache. I think the convience of knowing exactly where org, project, and version start and stop is worth the cost to browseablity. R, Nick
Re: Use of '/' in ???-specifier's
Nick Chalko wrote: Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. +1 Steve. R, Nick -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
RE: Use of '/' in ???-specifier's
From: Stephen McConnell [mailto:[EMAIL PROTECTED] Nick Chalko wrote: Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. +1 Steve. A repository URI cannot be parsed simply based on repository-uri. It needs to be used in conjunction with the other proposals before any information can be derived. As stated previously, the URI doesn't match the criteria supported by the other proposals. This doesn't mean that the URI is invalid, it simply means that it isn't supported by them. Tools that are based on the proposals should therefore ignore it. Alternative approaches would be to: . limit each *-specifier to a single path segment (i.e, disallow /) Hopefully, the proposals show that this is too restrictive . include delimeters in the URI E.g, http://repo.apache.org/organisation/apache/project/foo/version/... Duplicate information, and just plain *ugly*. -Tim
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: From: Stephen McConnell [mailto:[EMAIL PROTECTED] Nick Chalko wrote: Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. +1 Steve. A repository URI cannot be parsed simply based on repository-uri. It needs to be used in conjunction with the other proposals before any information can be derived. As stated previously, the URI doesn't match the criteria supported by the other proposals. This doesn't mean that the URI is invalid, it simply means that it isn't supported by them. Tools that are based on the proposals should therefore ignore it. Alternative approaches would be to: . limit each *-specifier to a single path segment (i.e, disallow /) Hopefully, the proposals show that this is too restrictive . include delimeters in the URI E.g, http://repo.apache.org/organisation/apache/project/foo/version/... Duplicate information, and just plain *ugly*. Tim: I'm really not agree or disagreeing at this time - I just have a feeling in my bones that something is wrong. As such - consider this as simple rambling by someone who has not captured the big picture. After heading down to the cafe for a quick break - when walking back my thinking is that maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. I can't get away from that conclusion that we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. But this presuposes that atrifact is something more abstract than a file - and I'm guessing that your idea of artifact is equivalent to file. Appologies here because I'm not keen on being the odd-guy out - and I don;t want to disrupt the flow. But at the same time I want to see a good result from this. And from that point of view - my own feeling is that we should *not* be focussing on the url as the base layer - but instead focus on what is the meta descriptor and its MIME relationship *then*focusus on how to access this via a url. But I could easily be totally wrong because I'm still in digesting/thinking mode. Cheers, Steve. -Tim -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
RE: Use of '/' in ???-specifier's
maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. At any of it does is establish a path to a logical artifact. Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. So your feeling is that once you have a URI for the root component for a tool, you want meta-data suitable for your tool to indicate the location(s) of other content, such as license, dependents, etc. Those location(s) can be specified either by a full URI, or after all of Tim's good work, by URI parts, which the specification tells us how to assemble. The latter is how I have been viewing things so far. The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? I'm not keen on being the odd-guy out I don't think that you are. There may be some undocumented assumptions going on, and this helps to clarify them. For example, the above may help explain to Adam why I have been unconcerned about the ability to unambiguously parse a URL, whereas I do care about being able to assemble one. --- Noel
Re: Use of '/' in ???-specifier's
Noel J. Bergman wrote: maybe the [organization]/[product] notion is artificial. What [organization]/[product] and [organization]/[product]/[version] do is to establish a path to an logical artifact. At any of it does is establish a path to a logical artifact. Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. we should not be focussing on the url as a spec - but instead we should be focussing on the url as a [artifact-identifier] and from that point on we should be using metadata to provide us with the information about organization, product name, available versions, etc. So your feeling is that once you have a URI for the root component for a tool, you want meta-data suitable for your tool to indicate the location(s) of other content, such as license, dependents, etc. Those location(s) can be specified either by a full URI, or after all of Tim's good work, by URI parts, which the specification tells us how to assemble. The latter is how I have been viewing things so far. The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? In principal ... yes. But I am making an assumption that a very simple named value pair metadata syntax could be assumed along with a meta mime type. References in that structure could be absolute or relative to the location of the metadata file. Releative to the java world - that schema could be equivalent to the Properties format (i.e. some-name = some-value). Given something like this - it becomes a lot simpler to seperate mechanics of access from logic of usage, while maintaining potential for cross-application interoperability (although that would require at least a very very small set of standard properties - e.g. language and application domain). Cheers, Steve. I'm not keen on being the odd-guy out I don't think that you are. There may be some undocumented assumptions going on, and this helps to clarify them. For example, the above may help explain to Adam why I have been unconcerned about the ability to unambiguously parse a URL, whereas I do care about being able to assemble one. --- Noel -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | ||
Use of '/' in ???-specifier's
Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. R, Nick
RE: Use of '/' in ???-specifier's
From: Nick Chalko [mailto:[EMAIL PROTECTED] Given this spec repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier What is the version of this URL http://repo.apache.org/org/apache/commons/nightly/alpha/1.0/foo.jar * Projet commons, version Nightly 1.0 alpha * Project commons-nightly, version 1.0 alpha * Project commons-nightly-alpah version 1.0 (release) I think we should tighten the spec enough so we can at least tell the access, product,version, and artifact specifiers appart. R, Nick The URI isn't valid, according to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier as a nightly build is an interim build: interim-build = interim-build-designation / version [ / interim-version ] interim-version = latest | MMDD [- HHMM [SS]] interim-build-designation = interim | nightly | snapshot | ... version = latest | *pchar IOW, one of alpha or 1.0 is invalid. However, given the URI: http://repo.apache.org/org/apache/commons/nightly/1.0/20031113/jars/foo-1.0. jar it is possible to determine the version using the common build version specifier and java artifact specifier proposals, by parsing the URI from right to left. It isn't possible to separate the organisation from the directory component of access-specifier however. e.g. given: http://repo.apache.org/org/apache/ it could be interpreted as: . directory = org, organisation = apache . directory = , organisation = org/apache -Tim
Re: Use of '/' in ???-specifier's
Tim Anderson wrote: The URI isn't valid, according to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersio nSpecifier -Tim Try this one http://repo.apache.org/org/apache/commons/alpha/1.0/foo.jar * Projet commons, version 1.0 alpha * Project commons-alpha, version 1.0 * Project alpha version 1.0 I know this is contrived, but it does highlight the inablity to tell where one specifier ends, and onther begins. R, Nick
