Robert,
<snip>
their systems. Is there anything screwy about picking the Spring
framework as the official container into which James is poured?
Couldn't that just be how James is shipped from the core team?
experienced has proved that it's better to be container agnostic
pheonix was hot five years ago. last year, spring was hot. who knows
what'll be hot next year?
yes, ship with bindings but free the core from container dependencies
All I was failing to communicate was, since James has to run standalone
somehow, Spring could be the choice this year for what container to drop
the POJO's in. So, Spring would be the officially supported platform -
the only one that the core James team needs to be savvy with, but by no
means would Spring be the only container that could host James. Sounds
like what's going to be hot next year will just be all hot air, so
picking Spring is probably an ok decision.
I'm just thinking from an executive decision-making standpoint, if the
team were to make a major call like that and not have Spring be just
some prototypical thingy, it might help focus refactoring efforts. And
for me personally, I would have something I could latch onto. (I "get"
POJO architectures. :)) Reading over the links Stefano provided, I see
the POJO subject has come up over and over again, even with some
specifics about what could and should be done there next.
Stefano, I also am liking what I see with Maven 2. Switching to that
for the build system would bring James more into accord with other
Apache projects that are multiproject as well.
Cheers,
Dave Woldrich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
