Re: Where to publish Xalan code on http://www.apache.org/dist (fwd)
I'd say it is a development snapshot. Brett has been working on the
site plugin, and looks like he published it to the wrong place.
On Tue, 11 Jan 2005 21:56:30 +0100 (MET), Henk P. Penning
[EMAIL PROTECTED] wrote:
Hi,
[ I cut this from another message ; I hope it is correct ]
--On Wednesday, January 5, 2005 6:43 AM +1100 Brett Porter
[EMAIL PROTECTED] wrote:
This is for Maven users (and possible future tools, eg I believe Ant 1.7
has repository support) to be able to get your releases easily (releases
only -
development snapshots to http://cvs.apache.org/repository).
This was put in 'java-repository/maven/poms/' just now :
Jan 11 11:43 maven-site-plugin-1.6-SNAPSHOT.pom
Jan 11 11:43 maven-site-plugin-1.6-SNAPSHOT.pom.md5
Just to make sure : isn't this a 'development snapshot' ?
Shouldn't this have gone to 'http://cvs.apache.org/repository' ?
HPP
_
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
http://www.cs.uu.nl/staff/henkp.html M [EMAIL PROTECTED] \_/
--
http://www.multitask.com.au/people/dion/
Re: Where to publish Xalan code on http://www.apache.org/dist (fwd)
On Tue, 11 Jan 2005 16:04:31 -0500, Mark R. Diggory [EMAIL PROTECTED] wrote: Mixed terminology again. if the SNAPSHOT refers to a fully sanctioned release not an interim or daily build, then the usage is fine. Remember in this case SNAPSHOT is no different than LATEST or CURRENT. I wish we could have Maven folks explore usage of a more accurate terminology for these. Huh? SNAPSHOT versions are never a 'fully sanctioned release' and are simply a point in time build. It is VERY different from CURRENT in the apache sense which means latest released. AFAIK, there's no confusion over this. -- http://www.multitask.com.au/people/dion/
Re: [jelly] Re: md5 errors in java-repository
I'll remove the snapshot jars published yesterday.
I'm not sure the maven jar:deploy-snapshot code could have updated
those other jars, but I'll look into the commands it runs under SSH.
On Thu, 02 Sep 2004 20:17:53 -0400, Mark R. Diggory
[EMAIL PROTECTED] wrote:
I'm forwarding this onto the Repository email list.
Dion, the reason I was suggesting it was your action is because files
also owned by yourself were added to the commons-jelly/jars directory. I
assume it was your upload of those files which altered them so that the
md5's no longer matched.
-rw-rw-r-- 1 dion apcvs 12377 Sep 2 00:39
commons-jelly-tags-validate-20040902.073836.jar
-rw-rw-r-- 1 dion apcvs 32 Sep 2 00:39
commons-jelly-tags-validate-20040902.073836.jar.md5
...
-rw-rw-r-- 1 dion apcvs 10343 Sep 2 00:39
commons-jelly-tags-velocity-20040902.073917.jar
-rw-rw-r-- 1 dion apcvs 32 Sep 2 00:39
commons-jelly-tags-velocity-20040902.073917.jar.md5
...
-rw-rw-r-- 1 dion apcvs 161479 Sep 2 00:08
commons-jelly-20040902.070806.jar
-rw-rw-r-- 1 dion apcvs 32 Sep 2 00:09
commons-jelly-20040902.070806.jar.md5
...
-rw-rw-r-- 1 dion apcvs 35076 Sep 2 00:21
commons-jelly-tags-xml-20040902.072037.jar
-rw-rw-r-- 1 dion apcvs 32 Sep 2 00:21
commons-jelly-tags-xml-20040902.072037.jar.md5
...
-rw-rw-r-- 1 mdiggory apcvs 11489 Sep 2 00:28
commons-jelly-tags-xmlunit-20030211.144251.jar
-rw-rw-r-- 1 mdiggory apcvs 33 Jan 19 2004
commons-jelly-tags-xmlunit-20030211.144251.jar.md5
So I was suspecting it was Dion because the published jars under his
name like those represented above got transferred last night to ibiblio:
http://www.ibiblio.org/maven/reports/apache/2004/09/02/apache-20040902-050103.txt
All I know is that there was a process running around midnight which
walked through this directory and updated jar files within it, breaking
some of the md5 signatures on files which were owned by me.
Henk P. Penning wrote:
On Fri, 3 Sep 2004, Dion Gillard wrote:
Date: Fri, 3 Sep 2004 09:11:25 +1000
From: Dion Gillard [EMAIL PROTECTED]
To: Henk P. Penning [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: md5 errors in java-repository
Sorry guys, I haven't updated those files?
.. then some of the 909 other members of group apcvs did it.
true, true. We need to get the permissions locked down.
IMHO, these files shouldn't be group writable ;
only the directories should be; now file ownership
means nothing.
Well, I'm unsure how different individuals are publishing, I assume most
are using maven, which will set files permission according to how it
coded in the Maven client. If the Maven client were configurable, then
maybe this could be managed.
I'm still very curious how java-repository is maintained
-- what stuff is added, and how
Really, its only supposed to be getting full releases published within it.
-- what stuff is deleted and when
Currently, release which are removed from the public should be removed.
Whouldn't it be easier if there was a config like
this-jar FROM that-dist-tgz GOES there
so that
-- 'this-jar' can be removed if 'that-dist-tgz' is gone
That would be managed by the project owners, like it is now.
-- installation in java-repository can be automated
Again, Maven, as a client is used to publish a release jar into the
repository based on the project that is being worked with on the client
side, the structure is fairly strict.
HPP
_
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
http://www.cs.uu.nl/staff/henkp.html M [EMAIL PROTECTED] \_/
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
--
http://www.multitask.com.au/people/dion/
Re: licensing issues for virtual artifacts (was RE: click through license support?)
Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 25/11/2003 07:23:15 PM: [EMAIL PROTECTED] wrote: Why don't we just focus on: a) getting an ASF-only repository up first, and b) Getting the management and tooling for that before taking on virtual hosting. I'm failing to see the requirement for us to do that *now*. Because Apache projects using the repository would need also non-asf jars that we don't want to distribute - virtual artifacts. And there are other places those jars can be found. I'm failing to see how this impacts a repo that stores ASF-only content. I agree it would be a nice to have, but is it a requirement for an ASF repo? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/
Re: click through license support?
Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 19/11/2003 01:31:13 AM: [EMAIL PROTECTED] wrote: Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 15/11/2003 10:00:07 PM: Tim Anderson wrote: ... A tool can 'screen scrape' the redirected page, prompt the user to accept the license and only download if the license is accepted, If the tool is made to work like a web browser, ie show the pages and then download when the user clicks on the button, IMHO it would be perfectly acceptable. But still illegal. I still don't understand why. I mean, if: 1- the program opens the browser on the product download page 2 - the user does the download steps as usual 3 - the program gets the downloaded artifact from the local download location Why would we be breaking the license? The only difference between this approach and the usual one is that the download location is linked. We've been down this road and are working with Sun on a solution. We have (had?) a tool that would do the above in Maven ages ago. Yes, I'm aware of that. See http://maven.apache.org/sun-licensing-journey.html Very good that you have this page, thanks for the pointer. For example, the JavaMail v1.3 BCL has Supplemental License Terms which state in Point 2. : ...Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Java applets or applications (Programs), (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. I don't think a repository for distributing jars fits the requirements for (i) or (ii), and may possibly break (iii). And I don't think the ASF would like to agree to (vi). -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/
RE: [proposal] java artifact specifier v0.1
Noel J. Bergman [EMAIL PROTECTED] wrote on 11/11/2003 07:33:53 AM: Why source and not sources? Plural form of type should be used consistently for naming directories. That's a bit nit-picky. Let's agree on the structure, and then worry about spelling. :-) I am still against versionless filenames: Why? KEYS, for example, need not have a version. Probably SHOULD not have a version, in fact. The latest version should be used. In most other Keys may indeed have a version. KEYS may not always be cumulative. And if it had a version number, wouldn't need to be. [snip] -- 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 [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
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: Road Map
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 [EMAIL PROTECTED] wrote on 08/11/2003 02:01:52 AM: I am not sure if my earlier mail made it to the list, I really want to see a different view of the URI http://host/group/project/type/id-version[-type][.ext] It seems like we are inclining towards the already existing Maven kind of URI. It has already proven its existence, instead of repeating the same thing, may be we should try to find a better one. How to make it more user friendly, better than what we have. As I stated earlier, most of the project names don't say what they are trying to solve, and there are a lot of different projects that try to solve almost the same problem like xerces, crimson... (we could have lot of legacy projects with new ones coming in, but they all aim to solve one specific thing) why not group them all together, make it easy for the user to go to one place and decide on what they want. And the user need not know the project per say and all they need to know is what they want to solve. Remember, the drive here is to create an ASF hosted and usable repo, not necessarily to define all repos everywhere. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: URI Syntax was: Repository
Nick Chalko [EMAIL PROTECTED] wrote on 31/10/2003 08:38:36 AM: Since this is an ASF repo, isn't the ASF project name enough? I think I would still prefix it with apache, so that other organizations can follow our pattern with out conflicts. Also allowing other repositories to host artifacts from multiple orginizations. Sounds like a good idea. There is still some naming details to work out. An apache project can be a very big thing. Take the CLI project in Jakarta commons that would be apache-jakarta-commons-cli vs the pacakge name org.apache.commons.cli This is where the previous naming convention breaks for me. site/project/version/artifact-version.type assumes that the 'project' has a single versioning system. Jakarta as a project doesn't. e.g. commons/beanutils has versions very different from commons/logging. *As an example only*, maven treats commons/beanutils and commons/logging as two separate projects. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: What does the repository enable?
Hi Ted, from my POV, the repository isn't only about jars and classpaths. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au -Ted Leung [EMAIL PROTECTED] wrote: - To: [EMAIL PROTECTED] From: Ted Leung [EMAIL PROTECTED] Date: 03/09/2003 10:31AM Subject: What does the repository enable? 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
