You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Siegfried Goeschl <si...@it20one.at> on 2005/05/17 10:22:05 UTC
Re: YAAFI/Fortress
Hi Peter,
my comments are below
Peter Courcoux wrote:
> Siegfried,
>
> I had a quick look at YAAFI and perused the excalibur lists over the
> weekend.
>
> It looks like Fortress is still being actively developed, is used
> quite extensively and fits the style of component management required
> by turbine ( ie not wiring comoponents together but making them
> available in a similar manner to ECM).
Same for YAAFI ...
> I also note that Fortress has cyclic dependency checking, the lack of
> which in ECM, was a worry to me in a recent project where I had a
> number of junior developers writing and using ECM managed components.
This is a design problem and not a container problem ... :-) .... and
YAAFI is actually unable to run services with cyclic dependencies.
>
> It doesn't look to me like YAAFI has cyclic dependency checking and I
> think it might be worth looking at how we could use Fortress and what
> it would take to convert the fulcrum services to be usable in
> Fortress. It is more work but I'm thinking that biting the bullet now
> would have many advantages in the future.
We already took a few bullets - the Turbine services were converted to
ECM and then to Merlin thereby effectively stalling the Fulcrum project.
I don't have a problem migrating the existing codebase to use Fortress
but this involves the following steps
1) changing the access to the Avalon context for all services - not a
big deal and YAAFI supports setting up the correct Avalon context based
on the "componentFlavour"
2) writing role configuration files but I found nowhere a spec saying
how to write such a file for Fortress - and I need to write a parser for it
3) sorting out the dependencies and adding them to Fulcrum/Turbine -
Fortress requires around 20 JARs whereas YAAFI is happy with just two of
them.
>
> What do you think?
+) making Fulcrum components compatible to Fortress is a good idea
+) using Fortress as default Avalon container is currently not on my
list - but again this is my strictly personal opinion.
Cheers,
Siegfried Goeschl
>
> Regards,
>
> Peter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: YAAFI/Fortress
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
Comments below :
Siegfried Goeschl wrote:
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
>> Siegfried,
>>
>> I had a quick look at YAAFI and perused the excalibur lists over the
>> weekend.
>>
>> It looks like Fortress is still being actively developed, is used
>> quite extensively and fits the style of component management required
>> by turbine ( ie not wiring comoponents together but making them
>> available in a similar manner to ECM).
>
>
> Same for YAAFI ...
Agreed.
>
>> I also note that Fortress has cyclic dependency checking, the lack of
>> which in ECM, was a worry to me in a recent project where I had a
>> number of junior developers writing and using ECM managed components.
>
>
> This is a design problem and not a container problem ... :-) .... and
> YAAFI is actually unable to run services with cyclic dependencies.
>
Mmm. but it would be nice to know, sooner rather than later.
>>
>> It doesn't look to me like YAAFI has cyclic dependency checking and I
>> think it might be worth looking at how we could use Fortress and what
>> it would take to convert the fulcrum services to be usable in
>> Fortress. It is more work but I'm thinking that biting the bullet now
>> would have many advantages in the future.
>
>
> We already took a few bullets - the Turbine services were converted to
> ECM and then to Merlin thereby effectively stalling the Fulcrum
> project. I don't have a problem migrating the existing codebase to use
> Fortress but this involves the following steps
> 1) changing the access to the Avalon context for all services - not a
> big deal and YAAFI supports setting up the correct Avalon context
> based on the "componentFlavour"
> 2) writing role configuration files but I found nowhere a spec saying
> how to write such a file for Fortress - and I need to write a parser
> for it
> 3) sorting out the dependencies and adding them to Fulcrum/Turbine -
> Fortress requires around 20 JARs whereas YAAFI is happy with just two
> of them.
>
Good reasons for sticking with YAAFI :-)
>>
>> What do you think?
>
>
> +) making Fulcrum components compatible to Fortress is a good idea
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
>
Seeing as you are currently putting more work in on this, I think your
personal opinion counts.
There are other things I don't like about Fortress. For example the use
of javadoc tags, the need for an additional ant task and .xinfo files.
On balance I'm happy to give YAAFI a +1 and see how it goes. I've just
started a new Turbine project so I'll be using and testing it.
Regards,
Peter
> Cheers,
>
> Siegfried Goeschl
>
>>
>> Regards,
>>
>> Peter
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: YAAFI/Fortress
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
I'm currently not convinced about the POJO approach but I did not do any
work with Pico/Nano, Hivemind or Spring ... :-)
The trouble with all of those discussions is
+) that choosing a IOC container is a matter of personal taste
+) the complexity does not disappear - it is either within the
application code or the configuration file
+) that it adds no value to existing services and for the caller of the
service, e.g. for a new and moderate complex J2EE project I would use
Spring not because it uses a cool IOC framework with POJOs but for
having a bunch of functionality solving a lot of my problems. And if I
need a couple of Fulcrum services I would just write a YAAFI component
for Spring.
Having said that I'm leaning towards embedding IOC containers within IOC
containers as long as it is transparent to the caller of the service -
which is unfortunately not the case for Turbine. It should be no problem
to embed YAAFI into Hivemind or Spring ....
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
>I would like to see a migration to Fortess occur at some time as well.
>However, I think the lesson that the Turbine/Fulcrum land can take is that
>depending on any one container is bad. Containers seem to come and go with
>amazing regularity, and we shouldn't depend on any of them.
>
>I am leaning towards any real code should be a POJO, with the appropriate
>interface layer for a specific container.
>
>I like YAAFI because it works. I don't know that I would write an application
>on it (although Siegfried would!), but I like that it fires up, runs the unit
>tests, and then quits.
>
>I wish we did have a unit testing strategy where we could test against ECM,
>YAAFI, and Fortress.
>
>I think it boils down to someone stepping up and doing the work. It doesn't
>sound like anyone has any real objection to supporting Fortress. And moving
>from ECM + Yaafi to Fortress + Yaafi sounds like a good approach. Especially
>with Fortress actually having a 1.1 release available.
>
>Eric
>
>On Tue, 17 May 2005 10:22:05 +0200, Siegfried Goeschl wrote
>
>
>>Hi Peter,
>>
>>my comments are below
>>
>>Peter Courcoux wrote:
>>
>>
>>
>>>Siegfried,
>>>
>>>I had a quick look at YAAFI and perused the excalibur lists over the
>>>weekend.
>>>
>>>It looks like Fortress is still being actively developed, is used
>>>quite extensively and fits the style of component management required
>>>by turbine ( ie not wiring comoponents together but making them
>>>available in a similar manner to ECM).
>>>
>>>
>>Same for YAAFI ...
>>
>>
>>
>>>I also note that Fortress has cyclic dependency checking, the lack of
>>>which in ECM, was a worry to me in a recent project where I had a
>>>number of junior developers writing and using ECM managed components.
>>>
>>>
>>This is a design problem and not a container problem ... :-) ....
>>and YAAFI is actually unable to run services with cyclic dependencies.
>>
>>
>>
>>>It doesn't look to me like YAAFI has cyclic dependency checking and I
>>>think it might be worth looking at how we could use Fortress and what
>>>it would take to convert the fulcrum services to be usable in
>>>Fortress. It is more work but I'm thinking that biting the bullet now
>>>would have many advantages in the future.
>>>
>>>
>>We already took a few bullets - the Turbine services were converted
>>to ECM and then to Merlin thereby effectively stalling the Fulcrum
>>project. I don't have a problem migrating the existing codebase to
>>use Fortress but this involves the following steps
>>
>>1) changing the access to the Avalon context for all services - not
>>a big deal and YAAFI supports setting up the correct Avalon context
>>based on the "componentFlavour" 2) writing role configuration files
>>but I found nowhere a spec saying how to write such a file for
>>Fortress - and I need to write a parser for it 3) sorting out the
>>dependencies and adding them to Fulcrum/Turbine - Fortress requires
>>around 20 JARs whereas YAAFI is happy with just two of them.
>>
>>
>>
>>>What do you think?
>>>
>>>
>>+) making Fulcrum components compatible to Fortress is a good idea
>>+) using Fortress as default Avalon container is currently not on my
>>list - but again this is my strictly personal opinion.
>>
>>Cheers,
>>
>>Siegfried Goeschl
>>
>>
>>
>>>Regards,
>>>
>>>Peter
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
>>For additional commands, e-mail: dev-help@excalibur.apache.org
>>
>>
>
>
>
>--
>OpenSource Connections (http://www.opensourceconnections.com)
>
>
>
>
Re: YAAFI/Fortress
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
I'm currently not convinced about the POJO approach but I did not do any
work with Pico/Nano, Hivemind or Spring ... :-)
The trouble with all of those discussions is
+) that choosing a IOC container is a matter of personal taste
+) the complexity does not disappear - it is either within the
application code or the configuration file
+) that it adds no value to existing services and for the caller of the
service, e.g. for a new and moderate complex J2EE project I would use
Spring not because it uses a cool IOC framework with POJOs but for
having a bunch of functionality solving a lot of my problems. And if I
need a couple of Fulcrum services I would just write a YAAFI component
for Spring.
Having said that I'm leaning towards embedding IOC containers within IOC
containers as long as it is transparent to the caller of the service -
which is unfortunately not the case for Turbine. It should be no problem
to embed YAAFI into Hivemind or Spring ....
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
>I would like to see a migration to Fortess occur at some time as well.
>However, I think the lesson that the Turbine/Fulcrum land can take is that
>depending on any one container is bad. Containers seem to come and go with
>amazing regularity, and we shouldn't depend on any of them.
>
>I am leaning towards any real code should be a POJO, with the appropriate
>interface layer for a specific container.
>
>I like YAAFI because it works. I don't know that I would write an application
>on it (although Siegfried would!), but I like that it fires up, runs the unit
>tests, and then quits.
>
>I wish we did have a unit testing strategy where we could test against ECM,
>YAAFI, and Fortress.
>
>I think it boils down to someone stepping up and doing the work. It doesn't
>sound like anyone has any real objection to supporting Fortress. And moving
>from ECM + Yaafi to Fortress + Yaafi sounds like a good approach. Especially
>with Fortress actually having a 1.1 release available.
>
>Eric
>
>On Tue, 17 May 2005 10:22:05 +0200, Siegfried Goeschl wrote
>
>
>>Hi Peter,
>>
>>my comments are below
>>
>>Peter Courcoux wrote:
>>
>>
>>
>>>Siegfried,
>>>
>>>I had a quick look at YAAFI and perused the excalibur lists over the
>>>weekend.
>>>
>>>It looks like Fortress is still being actively developed, is used
>>>quite extensively and fits the style of component management required
>>>by turbine ( ie not wiring comoponents together but making them
>>>available in a similar manner to ECM).
>>>
>>>
>>Same for YAAFI ...
>>
>>
>>
>>>I also note that Fortress has cyclic dependency checking, the lack of
>>>which in ECM, was a worry to me in a recent project where I had a
>>>number of junior developers writing and using ECM managed components.
>>>
>>>
>>This is a design problem and not a container problem ... :-) ....
>>and YAAFI is actually unable to run services with cyclic dependencies.
>>
>>
>>
>>>It doesn't look to me like YAAFI has cyclic dependency checking and I
>>>think it might be worth looking at how we could use Fortress and what
>>>it would take to convert the fulcrum services to be usable in
>>>Fortress. It is more work but I'm thinking that biting the bullet now
>>>would have many advantages in the future.
>>>
>>>
>>We already took a few bullets - the Turbine services were converted
>>to ECM and then to Merlin thereby effectively stalling the Fulcrum
>>project. I don't have a problem migrating the existing codebase to
>>use Fortress but this involves the following steps
>>
>>1) changing the access to the Avalon context for all services - not
>>a big deal and YAAFI supports setting up the correct Avalon context
>>based on the "componentFlavour" 2) writing role configuration files
>>but I found nowhere a spec saying how to write such a file for
>>Fortress - and I need to write a parser for it 3) sorting out the
>>dependencies and adding them to Fulcrum/Turbine - Fortress requires
>>around 20 JARs whereas YAAFI is happy with just two of them.
>>
>>
>>
>>>What do you think?
>>>
>>>
>>+) making Fulcrum components compatible to Fortress is a good idea
>>+) using Fortress as default Avalon container is currently not on my
>>list - but again this is my strictly personal opinion.
>>
>>Cheers,
>>
>>Siegfried Goeschl
>>
>>
>>
>>>Regards,
>>>
>>>Peter
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
>>For additional commands, e-mail: dev-help@excalibur.apache.org
>>
>>
>
>
>
>--
>OpenSource Connections (http://www.opensourceconnections.com)
>
>
>
>
Re: YAAFI/Fortress
Posted by Eric Pugh <ep...@www.opensourceconnections.com>.
I would like to see a migration to Fortess occur at some time as well.
However, I think the lesson that the Turbine/Fulcrum land can take is that
depending on any one container is bad. Containers seem to come and go with
amazing regularity, and we shouldn't depend on any of them.
I am leaning towards any real code should be a POJO, with the appropriate
interface layer for a specific container.
I like YAAFI because it works. I don't know that I would write an application
on it (although Siegfried would!), but I like that it fires up, runs the unit
tests, and then quits.
I wish we did have a unit testing strategy where we could test against ECM,
YAAFI, and Fortress.
I think it boils down to someone stepping up and doing the work. It doesn't
sound like anyone has any real objection to supporting Fortress. And moving
from ECM + Yaafi to Fortress + Yaafi sounds like a good approach. Especially
with Fortress actually having a 1.1 release available.
Eric
On Tue, 17 May 2005 10:22:05 +0200, Siegfried Goeschl wrote
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
> > Siegfried,
> >
> > I had a quick look at YAAFI and perused the excalibur lists over the
> > weekend.
> >
> > It looks like Fortress is still being actively developed, is used
> > quite extensively and fits the style of component management required
> > by turbine ( ie not wiring comoponents together but making them
> > available in a similar manner to ECM).
>
> Same for YAAFI ...
>
> > I also note that Fortress has cyclic dependency checking, the lack of
> > which in ECM, was a worry to me in a recent project where I had a
> > number of junior developers writing and using ECM managed components.
>
> This is a design problem and not a container problem ... :-) ....
> and YAAFI is actually unable to run services with cyclic dependencies.
>
> >
> > It doesn't look to me like YAAFI has cyclic dependency checking and I
> > think it might be worth looking at how we could use Fortress and what
> > it would take to convert the fulcrum services to be usable in
> > Fortress. It is more work but I'm thinking that biting the bullet now
> > would have many advantages in the future.
>
> We already took a few bullets - the Turbine services were converted
> to ECM and then to Merlin thereby effectively stalling the Fulcrum
> project. I don't have a problem migrating the existing codebase to
> use Fortress but this involves the following steps
>
> 1) changing the access to the Avalon context for all services - not
> a big deal and YAAFI supports setting up the correct Avalon context
> based on the "componentFlavour" 2) writing role configuration files
> but I found nowhere a spec saying how to write such a file for
> Fortress - and I need to write a parser for it 3) sorting out the
> dependencies and adding them to Fulcrum/Turbine - Fortress requires
> around 20 JARs whereas YAAFI is happy with just two of them.
>
> >
> > What do you think?
>
> +) making Fulcrum components compatible to Fortress is a good idea
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
>
> Cheers,
>
> Siegfried Goeschl
>
> >
> > Regards,
> >
> > Peter
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
--
OpenSource Connections (http://www.opensourceconnections.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: YAAFI/Fortress
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
Comments below :
Siegfried Goeschl wrote:
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
>> Siegfried,
>>
>> I had a quick look at YAAFI and perused the excalibur lists over the
>> weekend.
>>
>> It looks like Fortress is still being actively developed, is used
>> quite extensively and fits the style of component management required
>> by turbine ( ie not wiring comoponents together but making them
>> available in a similar manner to ECM).
>
>
> Same for YAAFI ...
Agreed.
>
>> I also note that Fortress has cyclic dependency checking, the lack of
>> which in ECM, was a worry to me in a recent project where I had a
>> number of junior developers writing and using ECM managed components.
>
>
> This is a design problem and not a container problem ... :-) .... and
> YAAFI is actually unable to run services with cyclic dependencies.
>
Mmm. but it would be nice to know, sooner rather than later.
>>
>> It doesn't look to me like YAAFI has cyclic dependency checking and I
>> think it might be worth looking at how we could use Fortress and what
>> it would take to convert the fulcrum services to be usable in
>> Fortress. It is more work but I'm thinking that biting the bullet now
>> would have many advantages in the future.
>
>
> We already took a few bullets - the Turbine services were converted to
> ECM and then to Merlin thereby effectively stalling the Fulcrum
> project. I don't have a problem migrating the existing codebase to use
> Fortress but this involves the following steps
> 1) changing the access to the Avalon context for all services - not a
> big deal and YAAFI supports setting up the correct Avalon context
> based on the "componentFlavour"
> 2) writing role configuration files but I found nowhere a spec saying
> how to write such a file for Fortress - and I need to write a parser
> for it
> 3) sorting out the dependencies and adding them to Fulcrum/Turbine -
> Fortress requires around 20 JARs whereas YAAFI is happy with just two
> of them.
>
Good reasons for sticking with YAAFI :-)
>>
>> What do you think?
>
>
> +) making Fulcrum components compatible to Fortress is a good idea
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
>
Seeing as you are currently putting more work in on this, I think your
personal opinion counts.
There are other things I don't like about Fortress. For example the use
of javadoc tags, the need for an additional ant task and .xinfo files.
On balance I'm happy to give YAAFI a +1 and see how it goes. I've just
started a new Turbine project so I'll be using and testing it.
Regards,
Peter
> Cheers,
>
> Siegfried Goeschl
>
>>
>> Regards,
>>
>> Peter
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: YAAFI/Fortress
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Tue, 2005-05-17 at 10:22 +0200, Siegfried Goeschl wrote:
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
> > Siegfried,
> >
> > I had a quick look at YAAFI and perused the excalibur lists over the
> > weekend.
> >
> > It looks like Fortress is still being actively developed, is used
> > quite extensively and fits the style of component management required
> > by turbine ( ie not wiring comoponents together but making them
> > available in a similar manner to ECM).
>
> Same for YAAFI ...
>
> > I also note that Fortress has cyclic dependency checking, the lack of
> > which in ECM, was a worry to me in a recent project where I had a
> > number of junior developers writing and using ECM managed components.
>
> This is a design problem and not a container problem ... :-) .... and
> YAAFI is actually unable to run services with cyclic dependencies.
Agreed, This problem gets worse if you have different release cycles
form those components.
>
> >
> > It doesn't look to me like YAAFI has cyclic dependency checking and I
> > think it might be worth looking at how we could use Fortress and what
> > it would take to convert the fulcrum services to be usable in
> > Fortress. It is more work but I'm thinking that biting the bullet now
> > would have many advantages in the future.
>
> We already took a few bullets - the Turbine services were converted to
> ECM and then to Merlin thereby effectively stalling the Fulcrum project.
> I don't have a problem migrating the existing codebase to use Fortress
> but this involves the following steps
How many times someone will have to do this again and again ?
I'm not really sure if this is working like this right now. But why
don't make Turbine container (avalon) agnostic ?
>
> 1) changing the access to the Avalon context for all services - not a
> big deal and YAAFI supports setting up the correct Avalon context based
> on the "componentFlavour"
> 2) writing role configuration files but I found nowhere a spec saying
> how to write such a file for Fortress - and I need to write a parser for it
It's really easy. I have all xingu.sf.net components using Fortress.
> 3) sorting out the dependencies and adding them to Fulcrum/Turbine -
> Fortress requires around 20 JARs whereas YAAFI is happy with just two of
> them.
>
> >
> > What do you think?
>
> +) making Fulcrum components compatible to Fortress is a good idea
+1
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
+1
>
> Cheers,
>
> Siegfried Goeschl
>
> >
> > Regards,
> >
> > Peter
> >
Cheers !
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: YAAFI/Fortress
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Tue, 2005-05-17 at 10:22 +0200, Siegfried Goeschl wrote:
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
> > Siegfried,
> >
> > I had a quick look at YAAFI and perused the excalibur lists over the
> > weekend.
> >
> > It looks like Fortress is still being actively developed, is used
> > quite extensively and fits the style of component management required
> > by turbine ( ie not wiring comoponents together but making them
> > available in a similar manner to ECM).
>
> Same for YAAFI ...
>
> > I also note that Fortress has cyclic dependency checking, the lack of
> > which in ECM, was a worry to me in a recent project where I had a
> > number of junior developers writing and using ECM managed components.
>
> This is a design problem and not a container problem ... :-) .... and
> YAAFI is actually unable to run services with cyclic dependencies.
Agreed, This problem gets worse if you have different release cycles
form those components.
>
> >
> > It doesn't look to me like YAAFI has cyclic dependency checking and I
> > think it might be worth looking at how we could use Fortress and what
> > it would take to convert the fulcrum services to be usable in
> > Fortress. It is more work but I'm thinking that biting the bullet now
> > would have many advantages in the future.
>
> We already took a few bullets - the Turbine services were converted to
> ECM and then to Merlin thereby effectively stalling the Fulcrum project.
> I don't have a problem migrating the existing codebase to use Fortress
> but this involves the following steps
How many times someone will have to do this again and again ?
I'm not really sure if this is working like this right now. But why
don't make Turbine container (avalon) agnostic ?
>
> 1) changing the access to the Avalon context for all services - not a
> big deal and YAAFI supports setting up the correct Avalon context based
> on the "componentFlavour"
> 2) writing role configuration files but I found nowhere a spec saying
> how to write such a file for Fortress - and I need to write a parser for it
It's really easy. I have all xingu.sf.net components using Fortress.
> 3) sorting out the dependencies and adding them to Fulcrum/Turbine -
> Fortress requires around 20 JARs whereas YAAFI is happy with just two of
> them.
>
> >
> > What do you think?
>
> +) making Fulcrum components compatible to Fortress is a good idea
+1
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
+1
>
> Cheers,
>
> Siegfried Goeschl
>
> >
> > Regards,
> >
> > Peter
> >
Cheers !
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: YAAFI/Fortress
Posted by Eric Pugh <ep...@www.opensourceconnections.com>.
I would like to see a migration to Fortess occur at some time as well.
However, I think the lesson that the Turbine/Fulcrum land can take is that
depending on any one container is bad. Containers seem to come and go with
amazing regularity, and we shouldn't depend on any of them.
I am leaning towards any real code should be a POJO, with the appropriate
interface layer for a specific container.
I like YAAFI because it works. I don't know that I would write an application
on it (although Siegfried would!), but I like that it fires up, runs the unit
tests, and then quits.
I wish we did have a unit testing strategy where we could test against ECM,
YAAFI, and Fortress.
I think it boils down to someone stepping up and doing the work. It doesn't
sound like anyone has any real objection to supporting Fortress. And moving
from ECM + Yaafi to Fortress + Yaafi sounds like a good approach. Especially
with Fortress actually having a 1.1 release available.
Eric
On Tue, 17 May 2005 10:22:05 +0200, Siegfried Goeschl wrote
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
> > Siegfried,
> >
> > I had a quick look at YAAFI and perused the excalibur lists over the
> > weekend.
> >
> > It looks like Fortress is still being actively developed, is used
> > quite extensively and fits the style of component management required
> > by turbine ( ie not wiring comoponents together but making them
> > available in a similar manner to ECM).
>
> Same for YAAFI ...
>
> > I also note that Fortress has cyclic dependency checking, the lack of
> > which in ECM, was a worry to me in a recent project where I had a
> > number of junior developers writing and using ECM managed components.
>
> This is a design problem and not a container problem ... :-) ....
> and YAAFI is actually unable to run services with cyclic dependencies.
>
> >
> > It doesn't look to me like YAAFI has cyclic dependency checking and I
> > think it might be worth looking at how we could use Fortress and what
> > it would take to convert the fulcrum services to be usable in
> > Fortress. It is more work but I'm thinking that biting the bullet now
> > would have many advantages in the future.
>
> We already took a few bullets - the Turbine services were converted
> to ECM and then to Merlin thereby effectively stalling the Fulcrum
> project. I don't have a problem migrating the existing codebase to
> use Fortress but this involves the following steps
>
> 1) changing the access to the Avalon context for all services - not
> a big deal and YAAFI supports setting up the correct Avalon context
> based on the "componentFlavour" 2) writing role configuration files
> but I found nowhere a spec saying how to write such a file for
> Fortress - and I need to write a parser for it 3) sorting out the
> dependencies and adding them to Fulcrum/Turbine - Fortress requires
> around 20 JARs whereas YAAFI is happy with just two of them.
>
> >
> > What do you think?
>
> +) making Fulcrum components compatible to Fortress is a good idea
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
>
> Cheers,
>
> Siegfried Goeschl
>
> >
> > Regards,
> >
> > Peter
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
--
OpenSource Connections (http://www.opensourceconnections.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: YAAFI/Fortress
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Tue, 2005-05-17 at 10:22 +0200, Siegfried Goeschl wrote:
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
> > Siegfried,
> >
> > I had a quick look at YAAFI and perused the excalibur lists over the
> > weekend.
> >
> > It looks like Fortress is still being actively developed, is used
> > quite extensively and fits the style of component management required
> > by turbine ( ie not wiring comoponents together but making them
> > available in a similar manner to ECM).
>
> Same for YAAFI ...
>
> > I also note that Fortress has cyclic dependency checking, the lack of
> > which in ECM, was a worry to me in a recent project where I had a
> > number of junior developers writing and using ECM managed components.
>
> This is a design problem and not a container problem ... :-) .... and
> YAAFI is actually unable to run services with cyclic dependencies.
Agreed, This problem gets worse if you have different release cycles
form those components.
>
> >
> > It doesn't look to me like YAAFI has cyclic dependency checking and I
> > think it might be worth looking at how we could use Fortress and what
> > it would take to convert the fulcrum services to be usable in
> > Fortress. It is more work but I'm thinking that biting the bullet now
> > would have many advantages in the future.
>
> We already took a few bullets - the Turbine services were converted to
> ECM and then to Merlin thereby effectively stalling the Fulcrum project.
> I don't have a problem migrating the existing codebase to use Fortress
> but this involves the following steps
How many times someone will have to do this again and again ?
I'm not really sure if this is working like this right now. But why
don't make Turbine container (avalon) agnostic ?
>
> 1) changing the access to the Avalon context for all services - not a
> big deal and YAAFI supports setting up the correct Avalon context based
> on the "componentFlavour"
> 2) writing role configuration files but I found nowhere a spec saying
> how to write such a file for Fortress - and I need to write a parser for it
It's really easy. I have all xingu.sf.net components using Fortress.
> 3) sorting out the dependencies and adding them to Fulcrum/Turbine -
> Fortress requires around 20 JARs whereas YAAFI is happy with just two of
> them.
>
> >
> > What do you think?
>
> +) making Fulcrum components compatible to Fortress is a good idea
+1
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
+1
>
> Cheers,
>
> Siegfried Goeschl
>
> >
> > Regards,
> >
> > Peter
> >
Cheers !
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: YAAFI/Fortress
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
Comments below :
Siegfried Goeschl wrote:
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
>> Siegfried,
>>
>> I had a quick look at YAAFI and perused the excalibur lists over the
>> weekend.
>>
>> It looks like Fortress is still being actively developed, is used
>> quite extensively and fits the style of component management required
>> by turbine ( ie not wiring comoponents together but making them
>> available in a similar manner to ECM).
>
>
> Same for YAAFI ...
Agreed.
>
>> I also note that Fortress has cyclic dependency checking, the lack of
>> which in ECM, was a worry to me in a recent project where I had a
>> number of junior developers writing and using ECM managed components.
>
>
> This is a design problem and not a container problem ... :-) .... and
> YAAFI is actually unable to run services with cyclic dependencies.
>
Mmm. but it would be nice to know, sooner rather than later.
>>
>> It doesn't look to me like YAAFI has cyclic dependency checking and I
>> think it might be worth looking at how we could use Fortress and what
>> it would take to convert the fulcrum services to be usable in
>> Fortress. It is more work but I'm thinking that biting the bullet now
>> would have many advantages in the future.
>
>
> We already took a few bullets - the Turbine services were converted to
> ECM and then to Merlin thereby effectively stalling the Fulcrum
> project. I don't have a problem migrating the existing codebase to use
> Fortress but this involves the following steps
> 1) changing the access to the Avalon context for all services - not a
> big deal and YAAFI supports setting up the correct Avalon context
> based on the "componentFlavour"
> 2) writing role configuration files but I found nowhere a spec saying
> how to write such a file for Fortress - and I need to write a parser
> for it
> 3) sorting out the dependencies and adding them to Fulcrum/Turbine -
> Fortress requires around 20 JARs whereas YAAFI is happy with just two
> of them.
>
Good reasons for sticking with YAAFI :-)
>>
>> What do you think?
>
>
> +) making Fulcrum components compatible to Fortress is a good idea
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
>
Seeing as you are currently putting more work in on this, I think your
personal opinion counts.
There are other things I don't like about Fortress. For example the use
of javadoc tags, the need for an additional ant task and .xinfo files.
On balance I'm happy to give YAAFI a +1 and see how it goes. I've just
started a new Turbine project so I'll be using and testing it.
Regards,
Peter
> Cheers,
>
> Siegfried Goeschl
>
>>
>> Regards,
>>
>> Peter
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: YAAFI/Fortress
Posted by Eric Pugh <ep...@www.opensourceconnections.com>.
I would like to see a migration to Fortess occur at some time as well.
However, I think the lesson that the Turbine/Fulcrum land can take is that
depending on any one container is bad. Containers seem to come and go with
amazing regularity, and we shouldn't depend on any of them.
I am leaning towards any real code should be a POJO, with the appropriate
interface layer for a specific container.
I like YAAFI because it works. I don't know that I would write an application
on it (although Siegfried would!), but I like that it fires up, runs the unit
tests, and then quits.
I wish we did have a unit testing strategy where we could test against ECM,
YAAFI, and Fortress.
I think it boils down to someone stepping up and doing the work. It doesn't
sound like anyone has any real objection to supporting Fortress. And moving
from ECM + Yaafi to Fortress + Yaafi sounds like a good approach. Especially
with Fortress actually having a 1.1 release available.
Eric
On Tue, 17 May 2005 10:22:05 +0200, Siegfried Goeschl wrote
> Hi Peter,
>
> my comments are below
>
> Peter Courcoux wrote:
>
> > Siegfried,
> >
> > I had a quick look at YAAFI and perused the excalibur lists over the
> > weekend.
> >
> > It looks like Fortress is still being actively developed, is used
> > quite extensively and fits the style of component management required
> > by turbine ( ie not wiring comoponents together but making them
> > available in a similar manner to ECM).
>
> Same for YAAFI ...
>
> > I also note that Fortress has cyclic dependency checking, the lack of
> > which in ECM, was a worry to me in a recent project where I had a
> > number of junior developers writing and using ECM managed components.
>
> This is a design problem and not a container problem ... :-) ....
> and YAAFI is actually unable to run services with cyclic dependencies.
>
> >
> > It doesn't look to me like YAAFI has cyclic dependency checking and I
> > think it might be worth looking at how we could use Fortress and what
> > it would take to convert the fulcrum services to be usable in
> > Fortress. It is more work but I'm thinking that biting the bullet now
> > would have many advantages in the future.
>
> We already took a few bullets - the Turbine services were converted
> to ECM and then to Merlin thereby effectively stalling the Fulcrum
> project. I don't have a problem migrating the existing codebase to
> use Fortress but this involves the following steps
>
> 1) changing the access to the Avalon context for all services - not
> a big deal and YAAFI supports setting up the correct Avalon context
> based on the "componentFlavour" 2) writing role configuration files
> but I found nowhere a spec saying how to write such a file for
> Fortress - and I need to write a parser for it 3) sorting out the
> dependencies and adding them to Fulcrum/Turbine - Fortress requires
> around 20 JARs whereas YAAFI is happy with just two of them.
>
> >
> > What do you think?
>
> +) making Fulcrum components compatible to Fortress is a good idea
> +) using Fortress as default Avalon container is currently not on my
> list - but again this is my strictly personal opinion.
>
> Cheers,
>
> Siegfried Goeschl
>
> >
> > Regards,
> >
> > Peter
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
--
OpenSource Connections (http://www.opensourceconnections.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org