On 1/8/07, Joerg Heinicke <[EMAIL PROTECTED]> 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
