myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Proposal: Elimiante jar files from SVN
Date Mon, 27 Jun 2005 07:26:59 GMT
On 6/26/05, Bruno Aranda <brunoaranda@gmail.com> wrote:
> And, returning to the developer POV, you might want the sources for two things:
> 
> 1. Take a glance to the code to see how something is implemented.
> 2. Develop and/or build from sources.
> 
> IMO, for both cases is easier to download the jars using the script.
> Probably, for #1 jars are not essential, so the checkout is faster and
> you can get to the code sooner. If you want to do #2, you will have to
> execute the build.xml file, so it is acceptable to download the
> dependencies at this stage. I only see one disadvantage (and many
> advantages) in this approach: you need to execute the build.xml being
> online, at least the first time.
> 
> By the way, bandwith would be divided between the source repository
> (ASF) and the binary repository (Ibiblio or similar). It is obvious
> than, as Craig pointed, in the jars-in-SVN approach Apache might have
> many copies of the same commons-whathever lib (one or more for every
> project, the same version or a different one), while the binary
> repository would contain only one per version.
> 

You so *totally* don't get it.

If the JAR files are checked in to the CVS or SVN repository, then
***100%*** of the bandwith costs for downloading those binary JARs
goes to the Apache Software Foundation, because doing a "cvs update"
or "svn update" to update your source repository will *always*
download the copy in the source repository (i.e. using ASF's
bandwidth).  There is no opportunity for the bandwidth costs to be
shared, because nobody downloading from the source repository will
ever be redirected to a mirror (where the bandwidth charges might be
redirected).

The technical and process reasons for not putting generated artifacts
into source repositories are still relevant (which, independent of the
cost issue, are sufficient to argue against such a practice) ... but
what you are proposing is that the ASF should pay for ***you*** (who
are checking out sources, presumably because you want to work on them)
can be lazy.  I'm not at ***all*** sympathetic -- I want the money
that is contributed to ASF's bandwidth to go towards supporting
***users*** of the software being downloaded.

Interestingly, this is a place where the ASF culture of meritocracy
plays a  positive role ... if you can't figure out what dependencies
you need to download separately, in order to compile the source, then
there is either a problem with the documentation for that project's
build environment, or laziness on the part of the developer in
following the provided instructions.  If you won't even read the
directions, then the problem is definitely in your court :-).  If you
read them but don't like them, then maybe the world doesn't really
need whatever contributions you might have made to the world had you
been able to compile that particular project.

NOTE -- most open source releases include a pointer to the
corresponding source distributions (or the source is embedded in a
binary release), which users can load into the relevant IDEs they are
using (to provide code completion and/or javadocs).  In addition, the
relevant ASF binary release packages we are talking about generally
include all the corresponding binary dependencies (unless there are
license related issues), so this thread ends up being totally about
developers who want to download the raw source code from the
appropriate CVS or SVN repository -- if that's you, then please get
used to downloading your own dependencies (or cajoling the committers
on the project in question to providing some easy mechanism to do
this).

Craig

Mime
View raw message