Ceki Gülcü wrote:
>
> Sam objects to early binding. In other words to packages
> assuming a certain version of a dependency project where
> different versions of the dependency package behave
> differently. Is that correct?
>
> I fail to see how this is *directly* related to putting
> binary files in CVS. Gump works regardless of what people
> put in their CVS modules. Right?
See below.
> So the automatic update done by CVS eases the distribution
> of binaries but also increases the communication/networking
> overhead. The overhead is particularly irritating if the
> changes in the binary are minor.
>
> In other words, putting binary files under CVS decreases the
> need for developer to developer communication but increases
> computer to computer communication. Cheers, Ceki
I think you are looking at the symptoms, not the root problem.
If you accept that you are in a world where interfaces that you are
depending on change frequently, then the problem to solve is optimizing the
communication paths.
I don't accept that reality.
I bet that 98% of the servlets out there would compile just fine against a
version of servlet.jar that was built two years ago. I bet that 98% of
these servlets will compile just fine against the version of servlet.jar
that will be built two years from now.
The same can not be said for applications which depend on avalon or
turbine. Not two years, not one year, not six months, not three months.
Heck, I doubt that 98% of the applications which depend on turbine would
compile against the version of turbine that WAS BUILT LAST NIGHT.
I have great sympathy for subprojects like jetspeed and cocoon who depend
on a long list of subprojects with little respect for their users. Their
only defense it to check in jars.
When I first got involved with Tomcat, it only worked well with the latest
Sun 1.2 JDK, on Solaris, with encoding en_US. It couldn't even compile
with Jikes. Now it works on a wide range of JDKs from a number of vendors
on a number of platforms (and handles encoding properly too). Why?
Thankfully both legal and technical problems prevented us from checking in
the JDK.
Gump doesn't solve these problems. Peter Donald has outsmarted it. Jason
van Zyl ignores it.
There are loud voices out there that say that version to version
compatibility isn't important. You know better than your customers as to
what versions they really want.
They used to say that version to version compatibility wasn't much of an
issue, but they don't say that much any more, thanks to Gump. In four
months, I have yet to have a clean run. Even if one excludes xml-cocoon1
from the picture.
I have found that I can't talk over them all at once, so I have resigned
myself to convincing people one at a time that version to version
compatibility really matters.
Ceki - you are one of the people I have convinced. Now look at the
dependencies of jakarta-log4j. You are one of the lucky ones - outside of
Ant, you depend on stable standards. And Ant has grown up to the point
where they are responsible. So, do you really care whether users use
whichever XML parser they happen to have on their local machine, or do you
really want to require them to download yet another XML parser? If they
happen to have jakarta-ant checked out, they already have three. I'll bet
any one of them will serve your needs.
I still think a single repository of stable jars is an excellent idea.
Whether that repository is implemented as a tar, in cvs, or named CJAN, I
care not. But IMHO, such a system only works if mix and match is made
possible first.
A final note. At http://jakarta.apache.org/velocity/ymtd/ymtd.html you
will find a comparison between Turbine/Velocity and Struts/JSP. I pretty
much agree with everything said there. But I'll place my bets on
Struts/JSP. Not because of some presumedly massive Sun marketing machine.
Not because it it technically better. But because I for one don't like
rewriting my applications every few months.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
