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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo