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]