For those unaware of what Gump is, it is an initiative that I started last
year to see if I could help raise awareness of version compatibility issues
and increase the amount of timely communications between independent
subprojects. I am setting aside some time in the next week or two to try
to increase the documentation for this, but I decided to start with this
e-mail.
This is a general status report on the state of the various projects which
I try to follow with Gump. For those unaware of what Gump does - it
attempts to compile every project which I am following with either the
absolutely latest version of every dependency (from CVS) of other projects
I follow, or with a consistent set of dependencies (e.g. JDK version - I am
currently standardizing on Sun JDK 1.3). You can see current results at
http://jakarta.apache.org/builds/gump/latest/.
Periodically, I identify potential issues. In many cases, the immediate
reaction is why are you singling out my project?. Nothing could be
further from the truth - I am trying to work with all projects in order to
increase the awareness of maintaining version to version backwards
compatibility. Furthermore, I understand that at times this is not
possible. What I would like to see is that such changes are only done
after careful consideration and public discussion of the implications.
Here are a list of the issues I am currently tracking. Request: please do
not reply back to the general lists with rationale for individual changes -
please simply consider working with the affected parties to mitigate the
impact of the changes.
DOM3 adds methods to the DocumentImpl interface. This requires source
code changes in projects which implement this interface. This affects
dbxml.
Despite the relatively recent release of Ant, most Avalon projects will
not build with that version of Ant. They require a small but important
change in the jar task. Of course, they build with the version of Ant
checked into their respective cvs's, but the question is: do we really
want or need a separate version of Ant for every component?
The xml-batik project is in the process of changing the method
signatures in 10 methods of a public interface implemented by fop.
Since cocoon builds upon both fop and batik, all projects will need to
step up at once. Of course, other non-Apache projects build upon
cocoon, and coordinating everybody is not a viable option.
The Jakarta commons project latka is contemplating an alpha. Part of
their functionality is based on code contained in the HttpClient commons
project. Or rather, was contained there - it was rolled back. In order
to build latka, one needs to use a version of HttpClient prior to the
rollback. There is no released version of latka.
Tyrex depends on log4j interfaces which were deprecated, an alternative
was publically released, and ultimately removed. I've repeatedly
submitted a patch to their mailing list, but have not heard a response
in either occasion.
Tomcat4 depends on interfaces which tyrex removed over six months ago.
Scarab depends on an unreleased snapshot of torque in order to build.
As far as I can tell, it will not build with the version contained in
any public releases of turbine, nor with the current cvs tip. I mention
this here, not because Scarab is a Apache project (it is not), but as an
example of the impact of changes that are made to Apache projects have
on others.
Based on inspection, I don't believe that turbine-2 and turbine-3 can
coexist in a classpath. The jakarta-jetspeed, jakarta-turbine-jyve, and
jakarta-turbine-orgami projects depend on turbine-2. The
jakarta-turbine-flux and scarab projects depend on turbine-3.
On a lighter note, cruise control - a project which is intended to help
with continuous integration based on an approach of testing every change
after a commit has failed to compile for me for over a week. The
problem? More open braces than close braces in a source file...
To help add balance to this picture, here are a few success stories:
For pretty much the past year, Ant has been virtually 100% upwards
compatible. The few exceptions were cases where project definitions
(presumably unintentionally) depended on bugs in prior versions of Ant.
In prior years, Ant was rather notorious for introducing breaking
changes in every release.
After literally years of experimentation and perennial alpha state,
Avalon and Turbine have released stable versions of their respective
code bases.
Projects like cocoon and jetspeed have been on the receiving end of a
number of patches of the form I have made a change to a component that
you use - here is a patch which makes you work again.
Projects like log4j and turbine are taking great care in carefully
marking interfaces as deprecated and only removing them after projects
have had