> This explains a lot. With no notification of failures, the Avalon
> Community have been moving along in ignorant bliss (relative to the
> James Commnity).
There are Avalon developers here on this mailing list aware of what is going
on. Some months ago, Paul Hammant kindly offered to keep James going well
with Phoenix, and to be responsible for changing the James infrastructure to
match changes in Phoenix; he was made a James committer for this purpose.
James has its own snapshot of Phoenix, allowing James and Phoenix to evolve
at their own pace.
Apparently, there was a decision made half a year ago to eliminate the
Component interface in favor of A-Better-Way. Because of some ... shall we
say "anemia" ... in the Mailet v1 API, there are Mailets that must get at
non-Mailet API functionality. They do that by requesting the
ComponentManager via MailetContext.getAttribute(), and going on from there.
It is not a problem to migrate the James code, but Paul has expressed
concern about third-party mailets (outside of the scope of the CVS).
My proposal is that Paul remove dependency upon the Component interface
within Jame's code, and support foreign matchers/mailets as follows. The
only documented way for a matcher/mailet to get the component manager is via
a specific mechanism, and the set of components is limited. We can provide
our own Component code that lies (and wraps) as necessary, until we can drop
that code entirely. James' stock matchers/mailets would show how to make
the transition.
Personally, I have no problem with Phoenix continuing to evolve, given that
they've accepted responsibility for converting James along.
Again, personally, I would not want James to build against the Phoenix
nightly builds. I'd prefer that it build against the snapshot that is part
of James.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
