On 1/8/07, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
Craig McClanahan <craigmcc <at> apache.org> writes:
> 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.
Good point.
Side notes (not invalidating the point): Maven has switched off enforcing
checksum match by default. Often projects would also not be buildable due
to
checksum mismatches in the dependencies. And: I have to trust Maven that
it
really checks every download.
Not necessarily ... people who are sufficiently concerned about this are
also setting up their own internal repositories, containing only the bits
they have vetted themselves, and with their own security settings.
* 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.
I guess that was the major driver for Maven et al.
Someone had asked earlier about how Commons projects accomplished this goal
before Maven. The answer was a convention for using Ant build.xml scripts
that referenced a series of "build.properties" files containing definitions
for things like what commons-digester.jar should I use. The highest level
such file consulted was your ${user.home}/build.properties, so it was
reasonably easy to enforce global usage of common dependencies, as long as
all the build scripts used the same variable names.
Not perfect by any means, but it was minimally acceptable.
but please let your user opt out of *only* being allowed to use the
version
> you shipped.
What do you have in mind? What's actually enforced? Does it relate to your
impact 2 which is somewhat shortened?
In your build script, don't hard code the build to use your particular
version of the dependency only. If I have my own version, I'm going to want
to use it universally.
Jörg
Craig
