At 20:16 12.04.2001 -0400, Sam Ruby wrote:
>I think you are looking at the symptoms, not the root problem.
We are thinking about the same issue from different angles. See below.
>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.
OK. This is a new working assumption. If you think about CVSing jar files as a defense
against code changes, then your remark about symptoms versus root problem makes sense.
>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.
It's actually the aspect that matters the most, for widely used projects that is. It
is perfectly OK to be adventurous until the API is actually relied upon by many
people. Backward compatibility is not exactly fun. There are different degrees of
backward compatibility. I am not sure if all code written for Tomcat 3.x will compile
or work under 4.0.
>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 am very grateful to you for hammering on the backward compatibility issue. The
current goal is to make log4j v1.1 to be 100% compatible with log4j v1.0.x in every
aspect. Our users should appreciate...
Now, regarding ant.jar checked in the log4j module, I don't see what the problem is.
The user can use whatever ant version she decides to use; log4j does not care. The
same goes for the xml parser. Hey, you can even use JDK 1.1.x. If the user does not
have ant.jar then there is a default one provided by the log4j CVS module (as well as
by the log4j distribution.) So as far as I see, there are no issues with log4j
including binaries in its CVS module. It's just a convenience feature with few or
negligible side effects.
The versioning issue that you raise is much more fundamental and somewhat orthogonal
to CVSed binaries (IMHO).
>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.
I'll let Jason and Jon comment, wouldn't want to touch this one with a 12 yard stick.
Cheers, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
