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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
