On 2/2/07, Danny Angus <[EMAIL PROTECTED]> wrote:
<snip>
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.
with the need to modularise, i think that there's now more convergence
towards this
given a little initial restructuring (moving code around), it should
be possible to gradually move code out from the pheonix deployment
module into separate modules.
phase 1: make space for modules within james server trunk
* server/trunk -> server/trunk/pheonix
phase 2: top level build
* create build.xml which delegates to pheonix/build.xml
phase 3: upgrade build:
* upgrade to ant 1.7 (the new features are *really* good)
* create stage subdirectory which is local only
* create buildtasks module to host build macros and ant tasks for
module builds
phase 3: create empty base module top to contain API interfaces
* create macros and tasks to support modular build
* create build-modules.xml to support common structure
* base builds copies artifacts into stage subdirectory
* pheonix build copies artifacts locally from stage
* create macros to allow easy generation of new modules
once this has been done, we can gradually pull code out of pheonix
into modules. we can also add new code in as modules. branches can
just branch the modules they need and keep the others on trunk.
if there's consensus about this approach, i'm willing to make time to
execute (unless someone beats me to it ;-)
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
