Is Eclipse relearning the painful lessons of the past?
I attended an Eclipse Callisto session this morning at JavaOne, presented by Mike Milinkovich and Bjorn Freeman-Benson of the Eclipse Foundation. Callisto, if you’re not familiar with it, is a brave exercise in release management being attempted by the Eclipse community. The goal is for 10 separate projects (including the Eclipse platform itself, BIRT, WTP, and 7 others) to have their next major versions released concurrently. This isn’t simply a scheduling exercise (though that would be fairly impressive by itself). They are also attempting to achieve compatibility, to a degree, between all of these projects.
As Mike and Bjorn were discussing the lessons the Eclipse Callisto team has learned to date, I was struck by how each lesson has strong analogies (if not direct similarities) to lessons that the JCP specification groups have learned when coordinating releases of J2EE/JavaEE. The Callisto effort surfaced numerous hidden API dependencies that pointed to specification ambiguities and/or gaps. They learned to appreciate the need for what Bjorn called "whole-chain testing", i.e., running tests that crossed project/API boundaries to ensure that the entire Callisto framework was consistent and sound. They discovered that N projects leads to NxN possible touchpoints, leading to explosive integration testing issues. They learned that each project within Eclipse wanted to maintain control of their destiny, and resisted changes to design, APIs and schedules imposed by the coordinated approach.
Sound familiar? This reads like the syllabus to a Developing Frameworks 101 seminar.
I’m not trying to disparage or minimize what Eclipse is doing with Callisto. Quite the opposite, I think it’s a good, ambitious, constructive effort for the involved communities. And, indeed, the Callisto and J2EE/JavaEE efforts are different in fundamental ways. Eclipse is building a product-oriented framework, while the JCP is building a specifications framework that supports products.
But institutional memory is a powerful thing when achieved, and expensive if not downright destructive when it’s lost. I walked out of this session wondering how the technology community could learn these lessons institutionally, rather than being doomed to repeat history. One answer is likely "people" - get the core of these communities to share these lessons in the form of sharing people. Are there others?
Perhaps if they standardized on the Maven and Continuum build tools they won't have to deal with disparate configurations as much.
Well, I don't think build tools are the source or the solution for the issues they discussed. Ant seems to be serving them pretty well on that front. They are hitting design and contract issues across the multiple projects at the level of their own APIs, which are much trickier to resolve than external library dependencies.