Re: Rsync Emails
Adam R. B. Jack wrote: I could possibly tweek it to not send an email if there are no new files being moved. Please do. regards Adam I am +1 to send the notices here if the mail is tweaked . smime.p7s Description: S/MIME Cryptographic Signature
Re: URI syntax
Michael Davey wrote: I'd suggest that the change to project be a mandate. The change could be considered a clarification to improve consistency in naming. The alternative would be to let, say, Commons Net define their project as commons-net while Commons IO may choose to call their project simply io. On problem is the word project is very overloaded. At apache Jakarta is a Project. a TLP but still a project. By using the term product, we are specifying that is a THING that we are shipping,to us, (the repo list) a product, is a thing that is versioned and distributed. So I am -0 on using the word project. R, Nick
Re: URI syntax
Disregard, I miss read this. Nick Chalko wrote: Michael Davey wrote: I'd suggest that the change to project be a mandate. The change could be considered a clarification to improve consistency in naming. The alternative would be to let, say, Commons Net define their project as commons-net while Commons IO may choose to call their project simply io. On problem is the word project is very overloaded. At apache Jakarta is a Project. a TLP but still a project. By using the term product, we are specifying that is a THING that we are shipping,to us, (the repo list) a product, is a thing that is versioned and distributed. So I am -0 on using the word project. R, Nick
Re: cool uris don't change, don't they ?
Patrick Chanezon wrote: Did you specify a lifecycle for artifacts, with some durations, and a process to decommision them ? Good question. This may be something to put to the board. My general thought are. Released version should live forever, unless a security or other fatal flaw is found in a release. As a minimum I think the latest version of each point release should be kept ie 1.2.x. R, Nick
Re: subproject URI naming convention
Tim Anderson wrote: Can you provide an example of a URI which can't be parsed? -Tim [1] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax *repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier* It defines *access-specifier* and *product-specifier*, but leaves *version-specifier* and *artifact-specifier* opaque, to be defined by language, platform, or artifact-specific best practices. Since version-specifier and artifact-specifier are opaque, there is no way to tell where product specifier ends. I know we have suggested version, and a Java artifact specifier. But what about other languages, Like the new cool O/S language foo. It's artifact's are called bars http://repo.com/org/foo/cat/dog/bars/bar.zip What is the product org.foo.cat or org .foo? Is cat the version name or is dog.? Perhaps there are two kings of bars, one for dogs and one for eggs. or what ever. If we want to leave version specifier and artifact specifier opaque then I think it is important to harden the product specifier. Some limits to version might be acceptable, but artifact should definitely be opaque. organization/project is a workable solution that lets a tool make intelligent guesses based on URI only,. I like the simplicity of Top level = Organization that distribute things 2nd level = A project. (a sub organizational unit that distributes artifacts) 3/4 level = Version, (interim builds take an extra level 4/5 = Artifacts stored any what a project likes. (with best practices for Java and other languages.) The ONLY limits we have on organization and project and version is it must be valid URI character and it can not be a / (ie pchar) R, Nick
Re: subproject URI naming convention
Tim Anderson wrote: 3. Change product-specifier so that it is opaque repository-uri = access-specifier / product-specifier / version-specifier / artifact-specifier product-specifier = path_segments . recommend that product-specifier contains: . reverse FQDN . project name . subproject name(s) . can scale to arbitrary levels of subprojects . tools must parse URIs right to left, in order to separate version-specifier and product-specifier . tools must derive organisation, project, and subproject information from meta-data E.g: http://repo.apache.org/org/apache/jakarta/commons/lang http://repo.apache.org/org/apache/xml/batik I'm beginning to prefer option 3. What is the minimum amount of Meta Data we can use to support this. I can see this as just arbitrary super-projects and a project is a dir that has a dist directory.. or something. But really what is an organization. what is a project what is a sub-project. In the end a leaf project is something that has distrabutables, like jar's or zip's for source files. Everything before that is just an arbitrary amount of grouping of projects So really it comes down to how many levels of groups to we want 1 or 2 or n. The fact that commons-lang and commons-io are both part of the same Jakarta Project has no meaning to a repository. Because of that I still support having a specific number of non optional project grouping levels. I feel grouping at the organization level is enough. but I am not against a mandatory second level but I would call it org/project-group/project R, Nick
Re: subproject URI naming convention
Tim Anderson wrote: The fact that commons-lang and commons-io are both part of the same Jakarta Project has no meaning to a repository. True, but users browsing the repository can find them easier if they are grouped together. The only difference between commons/lang and commons-langis the number of items in a directory. but again if we allow arbitrary number of / before the the artifact part how can we tell what the project is we are back to http://repo.com/alpha/beta/alpha/beta/dist/beta-alpha.zip http://repo.com/dist/nightly/dist/dist/dist/dist/foo.zip Silly examples but with out a RIGID spec it will happen. Someone will want to name thier project Alpha, or nightly or the orginaztion will be named dist or intrim or snapshot. Lets just pick a number of groupings one or two or three and stick with it. Allow the / to have special meaning. R, Nick
Re: URI proposals updated
Excelent work. I think this a very manageable set of specs. I have one question for the http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/CommonBuildVersionSpecifier MileStone builds (ala eclipse) are they a formal or interm. Interm I think. R Nick
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: licensing issues for virtual artifacts (was RE: click through license support?)
[EMAIL PROTECTED] wrote: I agree it would be a nice to have, but is it a requirement for an ASF repo? Agree, lets wrap up the other specs first. I think we should delay, but a week or two maybe enough. Comment on the / issue. Help decidce in the version name not allowing release or latest etc. When that is done, then we can come back to this. I do think with all of Tim's excelent work we can wrap this up in a week or two.
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
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
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: licensing issues for virtual artifacts (was RE: click through license support?)
Tim Anderson wrote: Can you clarify the licensing issues further? I'm having trouble seeing what the problems are. Suppose ASF has the following link in the repository: http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar This is a virtual artifact, not hosted at ASF. I think what you describe was fine. I was looking the otherway. The ability to host a jar and ensure that a user accepts a license first. So what would we need for a virutal artifact. A entry-url and the rest is up to the user/tool? R, Nick
Re: click through license support?
Tim Anderson wrote: This group could make recommendations as to how virtual artifacts could be supported. Agree that we should deal with license issue's and virutal artifacts when we take on metadata.
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: [proposal] URI Syntax - v0.2
Tim Anderson wrote: From a tool perspective, it can unambiguously locate a project when given inputs of: org.apache - must replace . with / before performing lookup org/apache oracle The implication of this is that generic tools can't parse the URI and determine what is part of the product-specifier and what is part of the version-specifier. However, I don't think this is unreasonable. There is no requirement that tools be able to parse URIs to extract meta-data. -Tim I think easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] URI Syntax - v0.2
Tim Anderson wrote: ink easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. I think I see, A tool only needs to be able to generate a URL given the org, project, version, and artifact name. No need to be able to parse a given URL back into it parts. I think I can live with that. -Tim smime.p7s Description: S/MIME Cryptographic Signature
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
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
Re: [VOTE] Where is version in UIR Syntax
Tim Anderson wrote: I have a few comments on the content of that page: 1. Not sure why the discussion and the proposals are separate, given the partial duplication of pros and cons for each. Would prefer to see these merged. Good point, feel free to merge them. and add your pro cons. We will need this for later, when people ask us Why, we can point them to the wiki summary. 2. Version be a mandatory component of artifact filename Pros: . Artifacts become identifiable when *downloaded* from the repository. . This is not compatible with the current ASF scheme. Neither maven, nor dist require version in the artifact filename. Cons: . Presumes to know requirements of other repository users, for which we have no requirements. 3. Version in directory Cons: . I don't see how the need for a 'latest' symbolic link is a con. There is no uniform way at ASF at the moment to indicate the latest version. . Scheme not currently used by ASF. 4. There has been no discussion on how to cope with nightly or snapshot builds, which could change the version syntax. E.g: 1. Subdir per build: http://repo.apache.org/apache/commons-cli/nightly/20031112/... http://repo.apache.org/apache/commons-cli/nightly/20031113/... 2. Embedded in version: http://repo.apache.org/apache/commons-cli/nightly-20031112/... http://repo.apache.org/apache/commons-cli/nightly-20031113/... I'm leaning towards the former, as browsing is simpler. OTOH, this then leads to the possibility of nightly, snapshot, release etc being mandatory in product-specifier: product-specifier = organisation / project / rtype / version rtype = nightly | snapshot | release | ... -Tim -Original Message- From: Nick Chalko [mailto:[EMAIL PROTECTED] Sent: Friday, 14 November 2003 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Where is version in UIR Syntax Current count. 2 For version dir with optional version on artifact name. 3 for version dir and versioned artifact name. Make sure you voice your opinion. Nick Chalko wrote: Lets see where we stand on the version. Please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIs VersionInURISytnax and vote for the Proposal you prefer. Add pro's and con's as you see fit. Lets see how close we are to a consensus so wee can move on to other parts of the URISyntax. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Where is version in UIR Syntax
Stephen McConnell wrote: Just based on opinions registered so far - it seems that the notion of version in the path has concensus and that the real question and difference between the two position holding attention is if a version in the filename should be manadatory or not. Is that a reasonable conclusions? Seems that is where we are at. To me I can live with either. R, Nick Stephen. smime.p7s Description: S/MIME Cryptographic Signature
[VOTE] Where is version in UIR Syntax
Lets see where we stand on the version. Please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInURISytnax and vote for the Proposal you prefer. Add pro's and con's as you see fit. Lets see how close we are to a consensus so wee can move on to other parts of the URISyntax. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Where is version in UIR Syntax
Current count. 2 For version dir with optional version on artifact name. 3 for version dir and versioned artifact name. Make sure you voice your opinion. Nick Chalko wrote: Lets see where we stand on the version. Please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInURISytnax and vote for the Proposal you prefer. Add pro's and con's as you see fit. Lets see how close we are to a consensus so wee can move on to other parts of the URISyntax. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Where to put Version in the URISyntax
Lets try to summerize the different positions and then come to a consensus on the wiki at http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/WhereIsVersionInURISytnax I am still trying to wade throught the 60 emails from this weekend. I would really appreciate the various pro's and con's summarized. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: Processing Versions
Michal Maczka wrote: I wrote: .. repository [...] won't be limited to projects hosted at ASF. In requirement list I can see: ASF Repository shall not Host any artifact in violation of a license, or IPR. And if anything was discussed before - above statement reflects well the temporary decision which was made and all the limitation which were considered. (temporary in that sense that anything is not written on the stone) Those are just my assertions. No one has objected so I suppose they are still the Requirements. smime.p7s Description: S/MIME Cryptographic Signature
Re: Road Map
[EMAIL PROTECTED] wrote: Start at, and hack away. http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository Nick, what's the wiki link? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc Nick Chalko [EMAIL PROTECTED] wrote on 08/11/2003 06:58:18 AM: Lets agree on some first steps to take We need to 1. Agree on Repository goals 2. Agree on Repository requirements 3. Agree on URI syntax 4. Recommend best practices for 1. Client Tools 1. Management Tools Then we can encourge / sponsor projects that write code. This assumes that this list is not about a particular code base, but about the Structure of a Apache Repository, a set of specification. I very much think that the steps must be done in order. If you agree please review and update the wiki so we can move forward. Otherwise we will go in circles. R, Nick
Re: Proposals
Anou Manavalan wrote: With repositories growing fast, it needs to be searched and there should be a keyword search that assists faster search ( speaking from the established UDDI Repository and Database point of view ). With no responses supporting this idea, I guess I will put this idea to rest in peace ;-) Added a may / second phase goal. We will need evenetually some metadata and metadata serach facilities. But later after the base URI is agreed upon. regards, -Anou _ Concerned that messages may bounce because your Hotmail account is over limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es smime.p7s Description: S/MIME Cryptographic Signature
Re: Proposals
Stephen McConnell wrote: Anou Manavalan wrote: With no responses supporting this idea, I guess I will put this idea to rest in peace ;-) Searching is certainly on the my agenda. We need it for IDE related development, repository management, and intelligent query based artifact aquisition (and HTTP in this context is not an ideal solution). HTTP is fine for searches http://repo.apahce.org/search/?keyword=cool Or something. returns some XML format or another. But first the simple URL then the search interfaces. smime.p7s Description: S/MIME Cryptographic Signature
re Group was Argrement #1? : Layout (aka URL)
Adam R. B. Jack wrote: Let's try to work this one through to completion: http://host/group/type/id[-version].ext So what should group be Given Noel's concern about Top Level Project and projects moving. I think that leaves us with the java package name. Allowing non java groups to use org.apache.tlp and then whatever. Also to keep the listing smaller can group be something like /apache/commons/beantuils or must it be apache-comons-beanutils. smime.p7s Description: S/MIME Cryptographic Signature
Re: metadata
Adam R. B. Jack wrote: Metadata: 3) Do we need per version metadata? Hmmm... :( I guess it's doable, tools could easily provide. The per id *.md5 or *.asc are such metadata. I think per version metadata can be just another TYPE of artifact stored in the repo baseurl/commons-beanutils/meta/depend.xml or something. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
How to reference projects in the Repository.
Here is the goals I think we shouould have for a project reference scheme. * Human Readable * globaly unique * stable over long periods of time If these are reasonable goals, then we should start evalutating the merrits of different approaches. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: Re: [VOTE] distribute the compiled .jar binaries as part of the /dist]
Costin Manolache wrote: On Tue, 8 Apr 2003, Nick Chalko wrote: I almost missed this thread. The jar repository issue continues. Except it's no longer the jar repository issue :-) Just use the /dist layout the way it is supposed to - i.e to distribute our releases. Jars are just one type of binary - and I think it should follow the same rules as .exe and .so and .tgz files ( from the point of view of the /dist layout ). If one or another repository is defined and distributes some jars in whatever layout - that's wonderfull, but so far all I'm concerned is that releases go to /dist, including binaries ( like .jars ). Costin I am very happy with that result. Once one projects starts. I will bug the otheres to follow suite. -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede -
Re: [proposal] URI format
Costin Manolache wrote: That's my plan as well, but before starting to bug tomcat, jakarta-commons, ant - I would like to know we are in agreement on this first step ( i.e. add the .jars as part of the current distribution format, with full name and symlink to latest release ) Costin Shall we call for a VOTE so we can move on? -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede -
Re: What does the repository enable?
Ted Leung wrote: Hi guys, I know I'm late to the party, but... I know that we're discussing URI format and Andy's writing code, and I have some code as well. One thing that I haven't seen here is what functionality we want to enable by having a repository.Here are some possible pieces: 1. Be able to download the jars that a project needs in order to get built 2. Be able to download the jars that a project need in order to run 3. Be able to generate the correct classpath so that a project can run 4. Allow the repository to be transparently mirrored world wide. 5. Allow the repository to be composed of multiple pieces, much like a UNIX filesystem allows mount'ing of filesystems. Are there any others? In the midst of the URI format and the XML descriptors, I'm having trouble seeing what we are trying to enable. Ted http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements This is a top of my head list of requirements for the Apache Software Repository * ASF Repository shall o only host artifacts approved by a PMC o be accessible to the public via http o be mirrorable. o allow browsing and downloding of artifacts by humans via normal web browser * ASF Repository should o provide metadata about a project, + its components + its dependencies + its artifacts + list of version available + url's to find specific versions of an artifact. o Provide tools for the management of the project metadata o Allow for low cost maintance by hand without tool support. * ASF Repository shall not o Host any artifact in violation of a license, or IPR. Wiki away and add stuff.
Re: What should be in the MetaData
This seems like a whole lot of XML for what is implicit in the URI and the manifest.
