On 2/3/07, David Woldrich <[EMAIL PROTECTED]> wrote:
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.
nothing wrong with your communication
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.
pheonix is an advanced and mature IoC container of the second generation. it runs the standalone application very well but requires custom adapters for other environments. spring is a third generation container and had the benefit of learning from drawbacks of the first and second generation containers but it's not as mature. switching from a mature container that's know to work well with james to spring would be risky and IMO it would be a poor trade.
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.
IMHO the biggest structural issue that james development has at the moment is not choice of container but a lack of modularization. there is too much code on branches which should be in experimental modules. it is too much work to move all the current code base to POJOs. we need to be able to port code gradually. there seems tentative consensus on my reorganisation idea so i'll push it forward to the next stage.
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.
the choice of build system is a religious subject from a technological perspective, both maven 2 and ant 1.7 work well with multi-project builds (though earlier versions of each library has drawbacks when used with multiple modules). from a pragmatic perspective, switching the creation of the standalone deployment to maven would require someone to invest several weeks in creating numerous custom plugins. (switching the proposed module builds to maven would be less effort.) not sure that anyone cares enough about the build system to win the religious war and then create the required plugins. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
