commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [all] jarfiles in svn
Date Mon, 08 Jan 2007 22:09:28 GMT
On 1/8/07, Joerg Heinicke <joerg.heinicke@gmx.de> wrote:
>
> Simon Kitching <skitching <at> apache.org> writes:
>
> > When using maven, only the first run needs to download the jars ... So,
> no need
> > for "internet access at build time".
> >
> > For ant ... This can be run *once* to download the jars, but is not part
> of the
> > main build task, so there is no need for "internet access at build
> time".
>
> Even if only for the first run you need a build environment for
> downloading the
> dependencies. That's the point.
>
> > > (I speak from experience. In my company ...)
> >
> > A poor corporate internet access policy at one company is *NOT* a good
> > justification for misusing the Apache SVN repository.
>
> 1. How can be a misuse what was (inevitably?) custom for years? I don't
> know how
> Jakarta Commons handled this before Maven. Of course SVN might not be
> perfect
> for it. But as long as infrastructure team does not even discourage from
> committing jars I don't see a real problem with it. And for commons
> transaction
> we talk about other magnitudes than for Cocoon (665 KB vs. 40-45 MB).
>
> 2. I don't give justifications for enacting a law or something like that.
> I only
> gave an argument which might be considered as well. Other examples might
> be
> imaginable. If it is common understanding to do it the other way, be it
> for
> unification or other reasons mentioned, I'm ok with it.


The problem here is not disk space or overhead on the SCM server (although
you won't hurt my feelings if you take actions that make the Apache
Subversion server run faster :-).  The problem is one of engineering best
practices.

Storing JAR files in your source repository (or pretty much any other
scenario where you check in things that have been generated, instead of
rebuilding them) has the following negative impacts:

* Bypasses the normal mechanisms people use to verify
  that the bits they are depending on have not been corrupted
  (either accidentally or maliciously).  A cautious downstream
  user will go directly to the origin for every package they
  depend on, and validate checksums and signatures.  You
  are asking your downstream users to trust *you* to not
  have messed with these jar files.

* Typically leads to a build environment where *only* the
  copy of the dependent jars in your repository are used.
  That makes life much harder for downstream users who
  might have several packages that need the same dependency,
  and need to be sure that their entire application

* Creates redundant copies of shared dependencies in the
  build environment of your downstream users (if they use
  lots of packages that follow the same practice).  It's one thing
  to make a mess of redundant copies on our own server.
  It's quite another thing to make a mess in your user's directory,
  for every user.

This is not the same as saying "do not distribute such jars in a binary
distribution."  That is a convenience that many projects offer ... but
please let your user opt out of *only* being allowed to use the version you
shipped.


Thanks for your understanding.
>
> Jörg


Craig

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message