Binaries in CVS isn't the problem, per se. Although they do tend to be large
and CVS doesn't do binary diffs and patches.

There are three flavours of binaries (jars) to worry about: External,
Jakarta, and Project.

External jars are things like jaxp, jmx, xerces and so on. They are outside
Jakarta control. If a project depends on them, it probably depends on
specific versions. In order to have repeatable builds from different
developers, having those under project configuration management is critical.
Otherwise you rely on the outside world to maintain the version you need.

Project jars are the ones that are produced by the project. For ant, to take
a random example, to include ant.jar in their repository would be
pathological. At best it represents a bootstrap problem (which ant does
have, and surmounts), at worst you never have the current target in cvs
because it is always out of date. Products of a build should not be
versioned. Sources should be.

The middle ground is where the 'fun' is. Should Cactus treat jakarta-servlet
as a foreign project, or should it treat it as a co-equal project. Answer
one way and you end up with A depending on a downlevel version of B, while B
depends on a downlevel version of A. A production deployment nightmare.
Answer the other and you run the risk that your release is contingent on
project C's, and they're behind schedule.

Gump is tending to show that the latter risk is minimal. Simply having it is
keeping people more honest about published interfaces. 

My preference is to CVS external binaries, and rely on dist builds for
propagating Jakarta jars. Or a build from a unified tree, the way Tomcat
used to be.

        -SMD
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to