Re: licensing issues for virtual artifacts (was RE: click through license support?)
On Nov 23, 2003, at 4:02 PM, Dirk-Willem van Gulik wrote: I'm the Apache JCP rep, and have had some talks with Sun about this issue. The object is to get a formal agreement from Sun to allow us to do this, without us having to try and interpret the license agreement. +1 to short circuit this and directly arrange the right thing with SUN; an das the ASF simply document a permission with them. We've got every indication from them that they _want_ these sort of things to be fixed - and not be a hurdle. I expect there to be enough trust between us and SUN that we can move the way/place/method of the click through. I've head that Jason has been having similar covnerstation - may be good for you two to sync up and make sure there is no overlap. There shouldn't be. I initially got the conversation going between Jason and Tom, but it stopped. I mentioned it to Graham at a JCP EC meeting to help get it jumpstarted again, thinking that it had sunk into the legal quagmire that can be the sun legal team :) geir Dw -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
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: Test/Prototypical Repository
Not quite. The log4j-1.2.8.zip binary should be log4j-1.2.8-bin.zip according to http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/JavaArtifacts I would expect the log4j 1.2.8 release (with debug versions of jars and binaries) to look something like: apache/ (organisation) log4j/ (project) latest/ - symlink to 1.2.8 1.2.8/ (version) binaries/ log4j-1.2.8-bin.tar.gz log4j-1.2.8-bin.tar.gz.md5 log4j-1.2.8-bin.tar.gz.pgp log4j-1.2.8-dbg-bin.tar.gz log4j-1.2.8-dbg-bin.tar.gz.md5 log4j-1.2.8-dbg-bin.tar.gz.pgp log4j-1.2.8-bin.zip log4j-1.2.8-bin.zip.md5 log4j-1.2.8-bin.zip.pgp log4j-1.2.8-dbg-bin.zip log4j-1.2.8-dbg-bin.zip.md5 log4j-1.2.8-dbg-bin.zip.pgp source/ log4j-1.2.8-src.tar.gz log4j-1.2.8-src.tar.gz.md5 log4j-1.2.8-src.tar.gz.pgp log4j-1.2.8-src.zip log4j-1.2.8-src.zip.md5 log4j-1.2.8-src.zip.pgp jars/ log4j-1.2.8.jar log4j-1.2.8.jar.md5 log4j-1.2.8.jar.pgp log4j-1.2.8-dbg.jar log4j-1.2.8-dbg.jar.md5 log4j-1.2.8-dbg.jar.pgp pgp/ KEYS licenses/ LICENSES.txt - Tim From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 November 2003 6:25 AM To: [EMAIL PROTECTED] Subject: Test/Prototypical Repository All, As a way to force me to review the specification and attempt to implement I've started a knock up repository at: http://www.apache.org/~ajack/testrepo [If we think this is a good idea we can ask infrastructure@ for a location we can all write to.] Can folks tell me if this repository fits the specification? I had problem with the top part. regards Adam -- Experience Sybase Technology... http://www.try.sybase.com
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: Test/Prototypical Repository
I'm still not convinced that binaries is better than binary as a type directory. See my original comments that must have lost in the ether (section 2) - http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1124258 Cheers, Ben Adam R. B. Jack wrote: All, As a way to force me to review the specification and attempt to implement I've started a knock up repository at: http://www.apache.org/~ajack/testrepo [If we think this is a good idea we can ask infrastructure@ for a location we can all write to.] Can folks tell me if this repository fits the specification? I had problem with the top part. regards Adam -- Experience Sybase Technology... http://www.try.sybase.com
