On Mon, Sep 15, 2008 at 11:16 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> On Mon, Sep 15, 2008 at 9:11 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >>> >>> Robert Burrell Donkin ha scritto: >>>> >>>> 1. spring-deployment is a (cool) spring based avalon container >>>> 2. pheonix-deployment is an avalon container >>>> 3. both depend on components coupled to intrusive avalon interfaces >>>> 4. the intrusive nature of avalon is bad for the code base >>>> >>>> this means that it's not going to be possible to factor out non-avalon >>>> components within the current layer structure. either >>>> spring-deployment needs to depend on pheonix-deployment or a new layer >>>> is going to be needed the functions and the avalon-containers. >>>> >>>> - robert >>> >>> This is a perfect summary of my previous concerns :-) >>> To be more precise spring-deployment is a spring based avalon container >>> compatible with phoenix configuration (config.xml) and descriptors >>> (xinfo) >>> so, there is something more than avalon in the coupling. >>> >>> I guess the ideas was to have spring as an avalon container so we could >>> move >>> some component out of avalon step by step. >> >> makes sense >> >>> ATM I'd probably choose the new layer type (-package). >>> ---- >>> sar-deployment >>> spring-avalon-package >>> phoenix-package >> >> is spring deployed through a SAR? > > No, but it depends on the content of the sar (including the config.xml, that > currently is duplicated in its own folder).
so AIUI the packages would contain only container binding code. deployment would depend on both packages and understand how to build both types of container. sounds good. which module would contain the avalon specific bindings? >>> BTW you are the ant build expert here, so do it as you feel it's better. >>> In >>> m2 we're using named dependencies so both solutions works the same. >> >> it's not an ant limitation but a self-imposed rule of the layering game > > You already told me, I know this. Maybe this is an english vs italian issue. > In italian a "limit" can be self imposed. "an ant limitation" implies that the fault lies with ant rather than a limit impose by the current build > I use "ant build" with specific reference to our current build based on ant. > I know ant can do anything that can be done in maven. It is the same as "you > can do in c anything you can do in c++". > >> IMHO james server is so complex from a coupling perspective that >> layering needs to be imposed to give an understandable structure. the >> rules of the layering may be expected to evolve with time. > > If it was for me we probably wouldn't have this self imposed limit, it's hopefully just a stage. it's only because the james component structure is so bad that it's necessary. once components have been factored > but I'm fine with it as long as we don't have to put in hacks to satisfy self > imposed limits. i'd much rather have temporary code hacks than modularisation hacks - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
