xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject Interproject dependencies, versioning issues, and gump
Date Tue, 18 Sep 2001 14:01:05 GMT
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 adequate opportunity to step up.  In the case of the pending
   deprecation of the log4j Category class, Ceki has indicated that he
   plans on keeping the old interface around for at least a year.

- Sam Ruby


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message