Re: MD5 and Mirrors ( was Re: MD5 Hash )

2004-02-11 Thread Mark R. Diggory
Its a tough call, is there any "standard" for the structure of the md5 contents out there? I think the Maven team would be keen to play along with a standard and yet play along with any configurability as well. -Mark Diggory Markus M. May wrote: Adam is perfectly right about this stuff. There is

MD% Standards (was Re: MD5 and Mirrors ( was Re: MD5 Hash ))

2004-02-11 Thread Mark R. Diggory
aven list too. http://www.faqs.org/rfcs/rfc1321.html A hard fast "dig" through the RFC suggests a loophole here as there is no reference to what the contents of a md5 signature fle should look like. Seems more of a inherant "suggestion" in the implementation itself. -Mark Mark R. D

Re: MD5 and Mirrors ( was Re: MD5 Hash )

2004-02-11 Thread Mark R. Diggory
Adam R. B. Jack wrote: Adam is perfectly right about this stuff. There is one more thing we need to think about. Some repositories treat md5-files different. The structure on apache.org is [filename - MD5 Hash]. But on ibiblio (maven-repository) it is just [MD5 Hash]. So this needs to be somehow c

Re: MD5 and Mirrors ( was Re: MD5 Hash )

2004-02-11 Thread Mark R. Diggory
Well, after my own little survey, I've determined the following: md5 on BSD (Apache Minotaur): [EMAIL PROTECTED]:/home/mdiggory> md5 foo.bar MD5 (foo.bar) = 7f5e787ff3b930d906d01243ccf7c237 md5 has no built in option to compare the file to the checksum and return true/false. Output of md5sum (GNU

Re: duplicate data

2004-03-07 Thread Mark R. Diggory
Sorry for the later response, currently, I think the major issues are in managing the content of java-repository in responsible manner. Key issues I can see needing to be addressed are the following. 1.) Get projects to be as "responsible" for their content in java-repository as they are for the

Re: Depot vs Avalon Repository

2004-03-10 Thread Mark R. Diggory
I'd like to also add that there is also a duplication of content between the "Avalon Repository" and the contents of the /www/www.apache.org/dist/java-repository (Maven Repository) which are used to publish all Apache content now to www.ibiblio.org/maven and provide alternative mirrors of the A

Re: Moving forward or letting go

2004-06-17 Thread Mark R. Diggory
Michael Davey wrote: Nicola Ken Barozzi wrote: It's some months that we have depot, and things have stalled. It happens in Opensource, and even big and succesfull projects have months that seems empty. But... Depot is not pushing, it's not getting used. We have to give it another push. I'll try

Re: Moving forward or letting go

2004-06-17 Thread Mark R. Diggory
Nicola Ken Barozzi wrote: Mark R. Diggory wrote: ... What about a "home"? Where will depot live as a tool? For example, is it appropriate as a Jakarta Commons Component? Growth will occur if the project is situated in the proper location such that users can find and will use it. H

Re: Moving forward or letting go

2004-06-20 Thread Mark R. Diggory
Lets not start a flame war, discussion here is how to get groups working together and find commonality in code and repository architecture etc, there are individuals who use and work on Maven present and in the discussion. Ultimately we seek standardization in repository structure and content s

Re: Moving forward or letting go

2004-06-21 Thread Mark R. Diggory
You might reword a sentance or two out of the first person, but feel free to reuse it. -Mark Nicola Ken Barozzi wrote: Mark R. Diggory wrote: Lets not start a flame war, discussion here is how to get groups working together and find commonality in code and repository architecture etc, there

Re: Download Manager

2004-07-13 Thread Mark R. Diggory
Adam R. B. Jack wrote: Ought we simple download it using Download-Manager w/ trusted? :) Ought we not simple copy it down to the local repository location? - copy file to a tmp-Directory with tmp-Name - check tmp file to MD5 - if correct, copy tmp file to local repository with correct name

Re: Download Manager

2004-07-13 Thread Mark R. Diggory
Adam R. B. Jack wrote: One thing I can chime in on here is that the mirror folks sure do like the idea of uploading to a staging area then copying to the desired location. It benefits their server side scripts to do this since an upload could take much longer time than a server side copy operation.

Re: TODOs

2004-07-13 Thread Mark R. Diggory
Adam R. B. Jack wrote: Ok, time to re-gen a set of todos since we have a few folks who are able to scratch this itch right now. Here are some things that come to my mind. 1) ASF Repository Find out more about what has been implemented in the name of the ASF Repository, and report to this list. I kn

Re: closer (was Re: TODOs)

2004-07-14 Thread Mark R. Diggory
Adam R. B. Jack wrote: "Mark R. Diggory" <[EMAIL PROTECTED]> wrote: ASF Repository: About this time what I'm maintaining is the following two repository directories: Thanks for this write-up. I haven't yet explored the idea of getting a "repository.apache

ASF Repository, closer.cgi and Depot

2004-07-14 Thread Mark R. Diggory
Sorry for the cross post but this seems relevant to both these groups. I was thinking about the subject of mirroring and redirection for the ASF Repository. Currently, there was some discussion on the Depot list concerning this. I feel we could address this subject again for both groups interest

Re: ASF Repository, closer.cgi and Depot

2004-07-14 Thread Mark R. Diggory
Erik Abele wrote: I suspect their views would include what you suggest, that distribution might save some nomimal (c.f. artifact sizes) bandwidth savings & give some CPU saving, but it'd be at significant loss of 'control' (of well behaved clients). Central control over this seems the most appeal