Re: [proposal] daedalus jar repository (was: primary distribution location)

[Leo Simons]

Costin Manolache wrote:
On Tue, 25 Feb 2003, Leo Simons wrote:
 

files in /dist/java-repository besides perhaps HEADER.html and 
README.htmls...
   

Few simple questions:
Should we use 2 different dirs for src and binary distribution ? Or maybe 
3 dirs ( src, bin, doc ) ? 

based on current practice at http://www.ibiblio.org/maven, the answer to 
both is "no". A quick
glance at the java projects @ http://www.apache.org/dist/ also seems to 
result in a "no". The
most standard practice seems to be to append -src or -bin, resulting in 
filenames of

/dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat}
/dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat}
where ${subproject} can be ".", and the /${version} part in the path is 
often ommitted.

Are "milestone" builds acceptable ? Should we get some weekly gump builds 
from HEAD into the repository ? 

That's up to each project to decide I think. My opinion is that once you 
provide a distribution of
a file, you need to keep providing it at the same URL for a timespan 
close to eternity. This seems a
good argument to not place milestones or weeklies here.

What policy should we use for removing older versions ( or we just keep 
everything ) ? 

my take: keep everything. Again, policy should be the same as for the 
contents of /dist/. I dunno
if there is an asf-wide policy for that...looking at 
http://www.apache.org/dist/httpd/old/, those guys
don't share my view :D

Since the versioned jar/unversioned dir format is used - I think various 
PMCs should try to get the various projects to use the same format internally. 
I would prefer the reverse ( versioned dirs / unversioned jars ) - but I 
can live with the reverse if it does have a "majority" support. 
Could we put at least this option to a vote, just to have a record that it
isn't just a random decision but what the committers really want ?

we could do that, but the big disadvantage with deviating from the 
existing maven/centipede/ruper
practice is that it deviates from that practice, thus requiring work and 
reducing compatibility. If you
feel like holding a vote, by all means feel free, I'll probably vote -1 
for deviating from the existing
format (unless you've got a good argument rather than preference; I 
share your preference but it
is just that ;)

cheers,
- Leo

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]