RE: Synchronizing James and Cornerstone

> Gump should have warned us before, but it has not been working
> for too much time. We have to fix it. Sam is helping everybody
> to get back to making Gump build everything

Sam is working hard, but one problem is that if GUMP can't successfully
build a dependency, then it can hardly report when that dependency changes
in such manner that when it finally builds it will break dependents.

One should support contracts for as long as possible, even if just for
binary compatibility.  Consider this example from the Servlet API: "In this
version, this method always returns null and remains only to preserve binary
compatibility. This method will be permanently removed in a future version
of the Java Servlet API.".  Does this mean that one can never remove them?
No, but there are ways to do it that are more graceful.

If I understand correctly, GUMP supports branchs and tags.  Before making
incompatible interface changes, the relevant Avalon CVS modules could have
been branched so that (a) GUMP could be told to build clients against a
particular branch, and (b) the module could patched if/when necessary to fix
a defect without requiring clients to adopt the new interfaces.  In other
words, if one is going to change a contract don't do so linearly.  I also
suggest that such changes only occur on major release boundaries.

> I have a better idea. We are floating the possibility of opening our
> Component repository to the projects that are using Avalon, and that
> would include James. Would that be a deal?

I just starting looking at your proposal.  It sounds as if it basically
would make Committers from Avalon-using projects Committers on the
components part of the Avalon landscape, and allow us to commit fixes to
Avalon components, e.g., Excalibur and Cornerstone.  Of course, you could do
that simply make us committers on those modules.

But we still need to change James because of interface changes, so unless
Avalon is proposing rolling back those changes (which might be even more
work at this point), I'm not sure how it is a better idea than updating
James with Stephen's help.

	--- Noel