www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@apache.org>
Subject Re: [proposal] daedalus jar repository (was: primary distribution location)
Date Wed, 26 Feb 2003 18:14:15 GMT
On Wed, 26 Feb 2003, Leo Simons wrote:

> >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

Well, the current practice at maven is one argument for "no", but its 
just one argument. 

The second argument is much better :-)

> /dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat}
> /dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat}

+1 then. 

> >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.

"up to each project" sounds fine. There are cases of long release cycles
where milestones make sense.

The main point for milestones and weeklies is to allow projects to use an
intermediary between Gump ( HEAD of everything ) and "latest release" of 
everything ( that can be old ). There are many cases like 
commons-el/jasper or tomcat/modeler where this middle ground is better. 

+1 for each project/PMC choosing what to publish/remove. 

> >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

What about a "at least 6 months and 2 versions back" ?

> >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 ;)

There are few good arguments for both ways.
If we host external packages - some licenses prohibit modifications of the 
binary distribution ( I read this as "you can't rename jars"). 

It also seems to be a very common practice - almost all projects I know 
use unversioned jars. I would say this beats the argument on the maven 
practice ( that ruper is also supporting ). I see no reason why 
a download tool can't accomodate both. 

On the other side - the practice on .so library supports the versioned
jars, as well as the ability to have all .jars in a single dir and use the
manifest to select the right version. 

I think a vote would be necesary - I'll probably propose it in the 
projects I participate in. Probably a global jakarta vote would also
make sense - at least to gather what's the majority things and recommend 

Since I don't think there is an absolute "right" - I obviously preffer a 
majority decision, that would justify some pushing and work to get it


To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message