avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Synchronizing James and Cornerstone
Date Sat, 11 Jan 2003 19:57:24 GMT
Stephen,

[Responding to all of your various notes here]

I don't know if Paul tagged the CVS when he took the code currently embedded
in James from the Avalon CVS.  Yes, it is certainly an older version of the
code prior to Avalon violating (er, unilaterally changing) interface
contracts.

> What I don't understand is how James could be running inside Phoneix
without
> problem unless nobody from James has executed a clean checkout of
> Excalibur in the last 3 months.

Of course we haven't:

   http://cvs.apache.org/viewcvs.cgi/jakarta-james/phoenix-bin/lib/
   http://cvs.apache.org/viewcvs.cgi/jakarta-james/lib/

As should be well understood by now, James uses the older version because
the interfaces were changed, and broke our code.  At some point, we had to
focus on our own release, and not play three-card monty with Avalon's
interfaces.

>    James is runing againt excalibur-thread-1.0.jar (size 22k)
>    Excalibur current build of excalibur-thread-1.0.jar (size 32k)
>    appears to be incompatible

Gee, what a shock.  And with the same version label, no less.

If I sound a bit testy today, I'm sorry (and probably a bit testy, anyway
:-)).  Reading your messages has me thinking about how much work and testing
we may have to do to get James running with the current Avalon.  Plus the
fact that this is still open despite being reported multiple times, put in
bugzilla, *and* having had the fix posted with it:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15296.

FWIW, we did take the file repository classes from Avalon and moved them
into our codebase because we were told that the code was in Avalon only for
us, and would not ever be fixed.

> Things would be *so* much easier if we got James and Cornerstone in sync.

Yes, getting back to the problem at hand ... how far have you gotten on all
of the problems you enumerated?

I'm willing to work with you on updating the HEAD to work with the curent
Avalon code.  I suspect that the best thing, so as not to foul up others
would be to create a short-lived branch of James, put the new Avalon jars in
that branch, and work on the James code until we can once again build and
run.  Then we can merge the Avalon jars and the changed code into HEAD.

And we can let GUMP warn us if someone changes interfaces again.

That the way you'd do it?

I don't see any value to changing the v2 branch to use the updated Avalon
interfaces.  Frankly, there is a trust factor, and I don't want to risk
breaking our stable branch.

> - Classes in James that extend Cornerstone and call super
>   on ComponentManager (which is broken because the Cornerstone
>   classes no longer implement ComponentManager.

>  - Numerouse casting errors related to James casting of objects
>    to Component which do not exist in the current Cornerstone
>    package.

>  - Some more tricky errors related to the passing of component
>    managers and component across different instances which don't
>    show up until runtime.

What about the other errors reported by GUMP, e.g.,

  org.apache.james.core.AvalonMailStore should be declared abstract;
  it does not define isSelectable(java.lang.Object)

  select(java.lang.Object) in org.apache.james.core.AvalonMailStore
  cannot implement select(java.lang.Object); attempting to use
  incompatible return type
     found   : org.apache.avalon.framework.component.Component
     required: java.lang.Object

Etc.  Are you including those errors, or have you fixed them already?

> In addition to synchronization I think there is some repackaging
> required on the Avalon side.

If we do it as suggested above, just package up the new Avalon jars to
replace what we have, get them to me, and I'll commit them.

	--- Noel


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message