Robert Burrell Donkin ha scritto:
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?
In the above tree all of the code is in the sar-deployment.
phoenix-package simply takes the sar and prepare packages adding the
phoenix-bin content.
spring-avalon-package would add spring and the avalon-spring-bridge-library.
Once all of our components will be free from avalon then we will be able
to introduce a spring-deployment (or spring-package) with no
dependencies on avalon-spring-bridge-library and sar-deployment.
In my opinion we could even decide that spring-avalon-package will be
our only new distribution and stop working on phoenix. To mantain 2
deployments without having tests is an effort. I use phoenix and its
ability to run multiple sars in the same contaier with isolated
classloaders but I bet I'm an isolated case and most james users simply
start phoenix with our bundled james.sar and nothing else.
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
From now on, if I'll use "ant limit" I will always refer to the limit
of our build based on ant. It's shorter to tell. I'll try to not use the
short form, if I remember.
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++".
[...]
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
