On 2/1/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Do I have your attention yet? :)
Yes :-)
I understand there are architectural thingies in James to consider and
phoenix and whatnot. I understand that there's a lot of time and
investment in the existing architecture. And I'm not suggesting that
James should not be able to run standalone, but I would like to be able
to optionally deploy James to Geronimo as a plugin. Has someone in the
know put any thoughts together on what it would take for this type of
deployment of James?
Yes, I have. Well not exactly, but it got your attention right? ;-)
We have an architecture which should lend itself well to james core
services being re-packaged for a whole range of deployment options. We
already have a sandbox fork which is deplyed in Springframework.
I posted this to the PMC list in q4 2004, when we were discussing what
to do about the closure of Avalon. Time has moved on since then but I
think it is still relevant:
... we slowly remove all trace of Avalon and Phoenix from James,
refactoring it into a "james-phoenix" deployment project and
leaving "our"
code as POJO's
Then we market James as container agnostic, supporting massive
extensibility/configurability, and invite container projects to create
other deployment packagers for James, MX or EJB/JCA or
Geronimo or Pico or
son-of-avalon, whatever. Let them compete to be the *best* container for
James, not the *only* container for James because James will be the only
sensible solution for proving a future proof mail framework.
Thats the crux of it really, make James not standalone but embedable by
design, any standalone distributions would be two things
James+deployment
code.
Encourage people to come in and contribute their "non-core" stuff, and
focus our limited bandwidth on creating deployment options for
James, make
james the ultimate chameleon, capable of being easily wrapped
to embed in
any Java container you want.
James should be easily extended anywhere, be that by adding
protocols, fast
fail storage, mailets, seive whatever.
Lets try to make James the R&D environment of choice for people who are
experimenting with changing the nature of mail, and the
discerning admins
choice for flexibility.
I think we've suffered a little from our lack of willingness to deviate
from design decisions in the face of requests from the real world, lets
open up the whole of James so that anyone can implement
anything, even if
it defies convention and breaks the rules.
Discussions with Dan Debrunner about a year later talked about
embedding James in Derby, as well as Derby in James, to produce a
mail-enabled database.
http://mail-archives.apache.org/mod_mbox/james-server-dev/200511.mbox/[EMAIL
PROTECTED]
What showstoppers are there?
Lack of available effort, and a clear set of refactoring goals is what
has foundered the effort so far.
We'd probably have to re-structure the project to have james core and
a number of deployment options, and we'd need to create the deployment
options. Nothing fatal that I can see.
If there was ever an
official James bug day, I would love to get involved, make some new
friends, and (especially) do some work towards the James-As-Plugin end...
Thats a nice idea, but we're a pretty global bunch and tend not to
work regular hours.
OTOH we've got a whole bunch of stuff in JIRA which you're welcome to
pick from.
In return we need to sort out our lifecycle so that you get the warm
glow from seing your fixes released, rather than languish in svn for
months on end.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
