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/10 14:12:05 UTC
Roadmap for Turbine 2.4 release?!
Hi folks,
are there any plans for a Turbine 2.4 M2 release?! Personally I would
like to use the Fulcrum components instead of Turbine components ... :-)
Cheers,
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Roadmap for Turbine 2.4 release?!
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
It sounds like we ought to use YAAFI. I'm keen to get rid of ECM.
Regards,
Peter
Siegfried Goeschl wrote:
> Hi Peter,
>
> Thoughts below :-)
>
> Peter Courcoux wrote:
>
>> Hi Siegfried,
>>
>> Thoughts below :-
>>
>> Siegfried Goeschl wrote:
>>
>>> Hi Peter,
>>>
>>> regarding the decision of choosing an Avalon container
>>>
>>> +) ECM is dead
>>
>>
>>
>> Agreed.
>>
>>> +) Merlin/Metro was never intended as embeddable Avalon container
>>> hence the problem with embedding it
>>
>>
>>
>>
>> Agreed.
>>
>>>
>>> +) Fortress is a valid choice but requires some work
>>
>>
>>
>> OK
>>
>>> +) YAAFI is used for Fulcrum builds the last 6 months
>>
>>
>>
>> I apologise for not having looked at YAAFI. In my ignorance I have
>> some questions :-
>>
>> Can we embed YAAFI as a service in turbine to replace ECM?
>>
>> Is this the right way to do it?
>>
>> How do you use YAAFI with turbine?
>
>
> In the YAAFI source tree there is a "contrib" directory which contains
> code for setting up YAAFI within Turbine. I need to check if it works
> with Turbine 2.4 CVS HEAD. And I use YAAFI in a Turbine 2.2
> application for nearly a year. Technically it is a copy-cat of the
> existing TurbineAvalonComponentService.
>
>>
>>>
>>> Having said that
>>>
>>> +) there is no need to deprecate ECM based services since they all
>>> run with YAAFI
>>> +) we use YAAFI and Fulcrum in production for serveral products now
>>
>>
>>
>> Fine.
>>
>> One last thought. Should we really be writing our own service
>> framework or using one written for us. If we use our own, it adds a
>> burden of maintaining it in the future. If Fortress is being actively
>> developed, should we try to use that instead so we gain the benefit
>> of not having to maintain our own. Can you summarise the advantages
>> of using YAAFI over Fortress. Hivemind seems to have a following as
>> well, but I haven't looked into that either. Do you know anything
>> about it?
>
>
> For background information about writing YAAFI checkout
> http://www.mail-archive.com/dev@excalibur.apache.org/msg01251.html and
> all the other messages in the thread.
>
> Comparing YAAFI with Fortress:
>
> +) it is a light-weight Avalon container only depending on the two
> Avalon Framework libraries and nothing else.
> +) it is able to run Avalon services written for any Avalon container
> - many Avalon services are not portable across Avalon containers
> +) it supports reconfiguration of individual or all services either by
> monitoring the configuration files or triggering it through the
> application
> +) it comes with an automated build, documentation, tutorial,
> regression tests and a test coverage of 75% - I hate to say it but
> YAAFI might be in a better shape than Fortress
>
> Regarding HiveMind - it is a different approach of an IOC container
> using "Constructor Dependcy Injection" or "Setter Dependcy Injection"
> whereas Avalon relies on using interfaces. Choosing an IOC container
> is a matter of personal taste but a sticky decision. Changing over to
> HiveMind requires rewriting all Fulcrum services therefore it is not
> an option. If you have some hours to spare/waste you can read the dev
> mailing list of the JAMES community - just check out POJO - they
> invest a huge amount of time and energy to replace the Avalon Phoenix
> container with something else using POJOs (Plain Old Java Objects).
>
> Conclusion:
>
> +) Fulcrum and Turbine in their current incarnation require an Avalon
> container
> +) There are a few Avalon container out there - ECM, ECM+ being used
> in Cocoon, Fortress, Phoenix, Loom, Plexus, Metro andYAAFI
> +) I agree that maintaining an Avalon container within Fulcrum is not
> a brilliant idea but there is no free lunch or "there is no container
> to rule them all"
>
>>
>> Regards,
>>
>> Peter
>>
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>
>>> Peter Courcoux wrote:
>>>
>>>> Siegfried,
>>>>
>>>> I think Eric Pugh and myself were the last people to work on the
>>>> 2.4 codebase. As far as I am concerned one major issue remains
>>>> which is that we are still using ECM as the container for Avalon
>>>> style components. I think that we need to make a decision on which
>>>> container to use and then embed it, deprecating the ECM based
>>>> service. I know lots of work has been done on YAAFI but have not
>>>> looked at it myself. Is this a reasonable option? I have lost track
>>>> of Fortress but this was the option we were favouring when we last
>>>> had time to look.
>>>>
>>>> As an aside, have you seen this :-
>>>> http://www.theserverside.com/articles/article.tss?l=IOCandEJB
>>>>
>>>> There is some work to be done in continuing the refactoring of the
>>>> RunData interface and implementation. I would like to effectively
>>>> replace RunData with PipelineData but keep a deprecated RunData
>>>> option for backwards compatibility. I'm not sure how long this
>>>> would take but I don't think it is too much work.
>>>>
>>>> That said, I have 2.4 in use in production, and it seems stable.
>>>>
>>>> I agree with you it would be nice to work towards a release.
>>>>
>>>> I'm at home at the moment so I'm not always at my desk, but I am
>>>> periodically on #turbine irc channel if you want to chat.
>>>>
>>>> Eric, do you have anything to add?
>>>>
>>>> Regards,
>>>>
>>>> Peter
>>>>
>>>> Siegfried Goeschl wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> are there any plans for a Turbine 2.4 M2 release?! Personally I
>>>>> would like to use the Fulcrum components instead of Turbine
>>>>> components ... :-)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Siegfried Goeschl
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: turbine-user-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
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-user-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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-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: Roadmap for Turbine 2.4 release?!
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
Thoughts below :-)
Peter Courcoux wrote:
> Hi Siegfried,
>
> Thoughts below :-
>
> Siegfried Goeschl wrote:
>
>> Hi Peter,
>>
>> regarding the decision of choosing an Avalon container
>>
>> +) ECM is dead
>
>
> Agreed.
>
>> +) Merlin/Metro was never intended as embeddable Avalon container
>> hence the problem with embedding it
>
>
>
> Agreed.
>
>>
>> +) Fortress is a valid choice but requires some work
>
>
> OK
>
>> +) YAAFI is used for Fulcrum builds the last 6 months
>
>
> I apologise for not having looked at YAAFI. In my ignorance I have
> some questions :-
>
> Can we embed YAAFI as a service in turbine to replace ECM?
>
> Is this the right way to do it?
>
> How do you use YAAFI with turbine?
In the YAAFI source tree there is a "contrib" directory which contains
code for setting up YAAFI within Turbine. I need to check if it works
with Turbine 2.4 CVS HEAD. And I use YAAFI in a Turbine 2.2 application
for nearly a year. Technically it is a copy-cat of the existing
TurbineAvalonComponentService.
>
>>
>> Having said that
>>
>> +) there is no need to deprecate ECM based services since they all
>> run with YAAFI
>> +) we use YAAFI and Fulcrum in production for serveral products now
>
>
> Fine.
>
> One last thought. Should we really be writing our own service
> framework or using one written for us. If we use our own, it adds a
> burden of maintaining it in the future. If Fortress is being actively
> developed, should we try to use that instead so we gain the benefit of
> not having to maintain our own. Can you summarise the advantages of
> using YAAFI over Fortress. Hivemind seems to have a following as well,
> but I haven't looked into that either. Do you know anything about it?
For background information about writing YAAFI checkout
http://www.mail-archive.com/dev@excalibur.apache.org/msg01251.html and
all the other messages in the thread.
Comparing YAAFI with Fortress:
+) it is a light-weight Avalon container only depending on the two
Avalon Framework libraries and nothing else.
+) it is able to run Avalon services written for any Avalon container -
many Avalon services are not portable across Avalon containers
+) it supports reconfiguration of individual or all services either by
monitoring the configuration files or triggering it through the application
+) it comes with an automated build, documentation, tutorial, regression
tests and a test coverage of 75% - I hate to say it but YAAFI might be
in a better shape than Fortress
Regarding HiveMind - it is a different approach of an IOC container
using "Constructor Dependcy Injection" or "Setter Dependcy Injection"
whereas Avalon relies on using interfaces. Choosing an IOC container is
a matter of personal taste but a sticky decision. Changing over to
HiveMind requires rewriting all Fulcrum services therefore it is not an
option. If you have some hours to spare/waste you can read the dev
mailing list of the JAMES community - just check out POJO - they invest
a huge amount of time and energy to replace the Avalon Phoenix container
with something else using POJOs (Plain Old Java Objects).
Conclusion:
+) Fulcrum and Turbine in their current incarnation require an Avalon
container
+) There are a few Avalon container out there - ECM, ECM+ being used in
Cocoon, Fortress, Phoenix, Loom, Plexus, Metro andYAAFI
+) I agree that maintaining an Avalon container within Fulcrum is not a
brilliant idea but there is no free lunch or "there is no container to
rule them all"
>
> Regards,
>
> Peter
>
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>> Peter Courcoux wrote:
>>
>>> Siegfried,
>>>
>>> I think Eric Pugh and myself were the last people to work on the 2.4
>>> codebase. As far as I am concerned one major issue remains which is
>>> that we are still using ECM as the container for Avalon style
>>> components. I think that we need to make a decision on which
>>> container to use and then embed it, deprecating the ECM based
>>> service. I know lots of work has been done on YAAFI but have not
>>> looked at it myself. Is this a reasonable option? I have lost track
>>> of Fortress but this was the option we were favouring when we last
>>> had time to look.
>>>
>>> As an aside, have you seen this :-
>>> http://www.theserverside.com/articles/article.tss?l=IOCandEJB
>>>
>>> There is some work to be done in continuing the refactoring of the
>>> RunData interface and implementation. I would like to effectively
>>> replace RunData with PipelineData but keep a deprecated RunData
>>> option for backwards compatibility. I'm not sure how long this would
>>> take but I don't think it is too much work.
>>>
>>> That said, I have 2.4 in use in production, and it seems stable.
>>>
>>> I agree with you it would be nice to work towards a release.
>>>
>>> I'm at home at the moment so I'm not always at my desk, but I am
>>> periodically on #turbine irc channel if you want to chat.
>>>
>>> Eric, do you have anything to add?
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> Siegfried Goeschl wrote:
>>>
>>>> Hi folks,
>>>>
>>>> are there any plans for a Turbine 2.4 M2 release?! Personally I
>>>> would like to use the Fulcrum components instead of Turbine
>>>> components ... :-)
>>>>
>>>> Cheers,
>>>>
>>>> Siegfried Goeschl
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: turbine-user-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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Roadmap for Turbine 2.4 release?!
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
Thoughts below :-)
Peter Courcoux wrote:
> Hi Siegfried,
>
> Thoughts below :-
>
> Siegfried Goeschl wrote:
>
>> Hi Peter,
>>
>> regarding the decision of choosing an Avalon container
>>
>> +) ECM is dead
>
>
> Agreed.
>
>> +) Merlin/Metro was never intended as embeddable Avalon container
>> hence the problem with embedding it
>
>
>
> Agreed.
>
>>
>> +) Fortress is a valid choice but requires some work
>
>
> OK
>
>> +) YAAFI is used for Fulcrum builds the last 6 months
>
>
> I apologise for not having looked at YAAFI. In my ignorance I have
> some questions :-
>
> Can we embed YAAFI as a service in turbine to replace ECM?
>
> Is this the right way to do it?
>
> How do you use YAAFI with turbine?
In the YAAFI source tree there is a "contrib" directory which contains
code for setting up YAAFI within Turbine. I need to check if it works
with Turbine 2.4 CVS HEAD. And I use YAAFI in a Turbine 2.2 application
for nearly a year. Technically it is a copy-cat of the existing
TurbineAvalonComponentService.
>
>>
>> Having said that
>>
>> +) there is no need to deprecate ECM based services since they all
>> run with YAAFI
>> +) we use YAAFI and Fulcrum in production for serveral products now
>
>
> Fine.
>
> One last thought. Should we really be writing our own service
> framework or using one written for us. If we use our own, it adds a
> burden of maintaining it in the future. If Fortress is being actively
> developed, should we try to use that instead so we gain the benefit of
> not having to maintain our own. Can you summarise the advantages of
> using YAAFI over Fortress. Hivemind seems to have a following as well,
> but I haven't looked into that either. Do you know anything about it?
For background information about writing YAAFI checkout
http://www.mail-archive.com/dev@excalibur.apache.org/msg01251.html and
all the other messages in the thread.
Comparing YAAFI with Fortress:
+) it is a light-weight Avalon container only depending on the two
Avalon Framework libraries and nothing else.
+) it is able to run Avalon services written for any Avalon container -
many Avalon services are not portable across Avalon containers
+) it supports reconfiguration of individual or all services either by
monitoring the configuration files or triggering it through the application
+) it comes with an automated build, documentation, tutorial, regression
tests and a test coverage of 75% - I hate to say it but YAAFI might be
in a better shape than Fortress
Regarding HiveMind - it is a different approach of an IOC container
using "Constructor Dependcy Injection" or "Setter Dependcy Injection"
whereas Avalon relies on using interfaces. Choosing an IOC container is
a matter of personal taste but a sticky decision. Changing over to
HiveMind requires rewriting all Fulcrum services therefore it is not an
option. If you have some hours to spare/waste you can read the dev
mailing list of the JAMES community - just check out POJO - they invest
a huge amount of time and energy to replace the Avalon Phoenix container
with something else using POJOs (Plain Old Java Objects).
Conclusion:
+) Fulcrum and Turbine in their current incarnation require an Avalon
container
+) There are a few Avalon container out there - ECM, ECM+ being used in
Cocoon, Fortress, Phoenix, Loom, Plexus, Metro andYAAFI
+) I agree that maintaining an Avalon container within Fulcrum is not a
brilliant idea but there is no free lunch or "there is no container to
rule them all"
>
> Regards,
>
> Peter
>
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>> Peter Courcoux wrote:
>>
>>> Siegfried,
>>>
>>> I think Eric Pugh and myself were the last people to work on the 2.4
>>> codebase. As far as I am concerned one major issue remains which is
>>> that we are still using ECM as the container for Avalon style
>>> components. I think that we need to make a decision on which
>>> container to use and then embed it, deprecating the ECM based
>>> service. I know lots of work has been done on YAAFI but have not
>>> looked at it myself. Is this a reasonable option? I have lost track
>>> of Fortress but this was the option we were favouring when we last
>>> had time to look.
>>>
>>> As an aside, have you seen this :-
>>> http://www.theserverside.com/articles/article.tss?l=IOCandEJB
>>>
>>> There is some work to be done in continuing the refactoring of the
>>> RunData interface and implementation. I would like to effectively
>>> replace RunData with PipelineData but keep a deprecated RunData
>>> option for backwards compatibility. I'm not sure how long this would
>>> take but I don't think it is too much work.
>>>
>>> That said, I have 2.4 in use in production, and it seems stable.
>>>
>>> I agree with you it would be nice to work towards a release.
>>>
>>> I'm at home at the moment so I'm not always at my desk, but I am
>>> periodically on #turbine irc channel if you want to chat.
>>>
>>> Eric, do you have anything to add?
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> Siegfried Goeschl wrote:
>>>
>>>> Hi folks,
>>>>
>>>> are there any plans for a Turbine 2.4 M2 release?! Personally I
>>>> would like to use the Fulcrum components instead of Turbine
>>>> components ... :-)
>>>>
>>>> Cheers,
>>>>
>>>> Siegfried Goeschl
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: turbine-user-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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Roadmap for Turbine 2.4 release?!
Posted by Peter Courcoux <pe...@courcoux.biz>.
Hi Siegfried,
Thoughts below :-
Siegfried Goeschl wrote:
> Hi Peter,
>
> regarding the decision of choosing an Avalon container
>
> +) ECM is dead
Agreed.
> +) Merlin/Metro was never intended as embeddable Avalon container
> hence the problem with embedding it
Agreed.
>
> +) Fortress is a valid choice but requires some work
OK
> +) YAAFI is used for Fulcrum builds the last 6 months
I apologise for not having looked at YAAFI. In my ignorance I have some
questions :-
Can we embed YAAFI as a service in turbine to replace ECM?
Is this the right way to do it?
How do you use YAAFI with turbine?
>
> Having said that
>
> +) there is no need to deprecate ECM based services since they all run
> with YAAFI
> +) we use YAAFI and Fulcrum in production for serveral products now
Fine.
One last thought. Should we really be writing our own service framework
or using one written for us. If we use our own, it adds a burden of
maintaining it in the future. If Fortress is being actively developed,
should we try to use that instead so we gain the benefit of not having
to maintain our own. Can you summarise the advantages of using YAAFI
over Fortress. Hivemind seems to have a following as well, but I haven't
looked into that either. Do you know anything about it?
Regards,
Peter
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Peter Courcoux wrote:
>
>> Siegfried,
>>
>> I think Eric Pugh and myself were the last people to work on the 2.4
>> codebase. As far as I am concerned one major issue remains which is
>> that we are still using ECM as the container for Avalon style
>> components. I think that we need to make a decision on which
>> container to use and then embed it, deprecating the ECM based
>> service. I know lots of work has been done on YAAFI but have not
>> looked at it myself. Is this a reasonable option? I have lost track
>> of Fortress but this was the option we were favouring when we last
>> had time to look.
>>
>> As an aside, have you seen this :-
>> http://www.theserverside.com/articles/article.tss?l=IOCandEJB
>>
>> There is some work to be done in continuing the refactoring of the
>> RunData interface and implementation. I would like to effectively
>> replace RunData with PipelineData but keep a deprecated RunData
>> option for backwards compatibility. I'm not sure how long this would
>> take but I don't think it is too much work.
>>
>> That said, I have 2.4 in use in production, and it seems stable.
>>
>> I agree with you it would be nice to work towards a release.
>>
>> I'm at home at the moment so I'm not always at my desk, but I am
>> periodically on #turbine irc channel if you want to chat.
>>
>> Eric, do you have anything to add?
>>
>> Regards,
>>
>> Peter
>>
>> Siegfried Goeschl wrote:
>>
>>> Hi folks,
>>>
>>> are there any plans for a Turbine 2.4 M2 release?! Personally I
>>> would like to use the Fulcrum components instead of Turbine
>>> components ... :-)
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-user-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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-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: Roadmap for Turbine 2.4 release?!
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
regarding the decision of choosing an Avalon container
+) ECM is dead
+) Merlin/Metro was never intended as embeddable Avalon container hence
the problem with embedding it
+) Fortress is a valid choice but requires some work
+) YAAFI is used for Fulcrum builds the last 6 months
Having said that
+) there is no need to deprecate ECM based services since they all run
with YAAFI
+) we use YAAFI and Fulcrum in production for serveral products now
Cheers,
Siegfried Goeschl
Peter Courcoux wrote:
> Siegfried,
>
> I think Eric Pugh and myself were the last people to work on the 2.4
> codebase. As far as I am concerned one major issue remains which is
> that we are still using ECM as the container for Avalon style
> components. I think that we need to make a decision on which container
> to use and then embed it, deprecating the ECM based service. I know
> lots of work has been done on YAAFI but have not looked at it myself.
> Is this a reasonable option? I have lost track of Fortress but this
> was the option we were favouring when we last had time to look.
>
> As an aside, have you seen this :-
> http://www.theserverside.com/articles/article.tss?l=IOCandEJB
>
> There is some work to be done in continuing the refactoring of the
> RunData interface and implementation. I would like to effectively
> replace RunData with PipelineData but keep a deprecated RunData option
> for backwards compatibility. I'm not sure how long this would take but
> I don't think it is too much work.
>
> That said, I have 2.4 in use in production, and it seems stable.
>
> I agree with you it would be nice to work towards a release.
>
> I'm at home at the moment so I'm not always at my desk, but I am
> periodically on #turbine irc channel if you want to chat.
>
> Eric, do you have anything to add?
>
> Regards,
>
> Peter
>
> Siegfried Goeschl wrote:
>
>> Hi folks,
>>
>> are there any plans for a Turbine 2.4 M2 release?! Personally I would
>> like to use the Fulcrum components instead of Turbine components ... :-)
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Roadmap for Turbine 2.4 release?!
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
regarding the decision of choosing an Avalon container
+) ECM is dead
+) Merlin/Metro was never intended as embeddable Avalon container hence
the problem with embedding it
+) Fortress is a valid choice but requires some work
+) YAAFI is used for Fulcrum builds the last 6 months
Having said that
+) there is no need to deprecate ECM based services since they all run
with YAAFI
+) we use YAAFI and Fulcrum in production for serveral products now
Cheers,
Siegfried Goeschl
Peter Courcoux wrote:
> Siegfried,
>
> I think Eric Pugh and myself were the last people to work on the 2.4
> codebase. As far as I am concerned one major issue remains which is
> that we are still using ECM as the container for Avalon style
> components. I think that we need to make a decision on which container
> to use and then embed it, deprecating the ECM based service. I know
> lots of work has been done on YAAFI but have not looked at it myself.
> Is this a reasonable option? I have lost track of Fortress but this
> was the option we were favouring when we last had time to look.
>
> As an aside, have you seen this :-
> http://www.theserverside.com/articles/article.tss?l=IOCandEJB
>
> There is some work to be done in continuing the refactoring of the
> RunData interface and implementation. I would like to effectively
> replace RunData with PipelineData but keep a deprecated RunData option
> for backwards compatibility. I'm not sure how long this would take but
> I don't think it is too much work.
>
> That said, I have 2.4 in use in production, and it seems stable.
>
> I agree with you it would be nice to work towards a release.
>
> I'm at home at the moment so I'm not always at my desk, but I am
> periodically on #turbine irc channel if you want to chat.
>
> Eric, do you have anything to add?
>
> Regards,
>
> Peter
>
> Siegfried Goeschl wrote:
>
>> Hi folks,
>>
>> are there any plans for a Turbine 2.4 M2 release?! Personally I would
>> like to use the Fulcrum components instead of Turbine components ... :-)
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Roadmap for Turbine 2.4 release?!
Posted by Peter Courcoux <pe...@courcoux.biz>.
Siegfried,
I think Eric Pugh and myself were the last people to work on the 2.4
codebase. As far as I am concerned one major issue remains which is that
we are still using ECM as the container for Avalon style components. I
think that we need to make a decision on which container to use and then
embed it, deprecating the ECM based service. I know lots of work has
been done on YAAFI but have not looked at it myself. Is this a
reasonable option? I have lost track of Fortress but this was the option
we were favouring when we last had time to look.
As an aside, have you seen this :-
http://www.theserverside.com/articles/article.tss?l=IOCandEJB
There is some work to be done in continuing the refactoring of the
RunData interface and implementation. I would like to effectively
replace RunData with PipelineData but keep a deprecated RunData option
for backwards compatibility. I'm not sure how long this would take but I
don't think it is too much work.
That said, I have 2.4 in use in production, and it seems stable.
I agree with you it would be nice to work towards a release.
I'm at home at the moment so I'm not always at my desk, but I am
periodically on #turbine irc channel if you want to chat.
Eric, do you have anything to add?
Regards,
Peter
Siegfried Goeschl wrote:
> Hi folks,
>
> are there any plans for a Turbine 2.4 M2 release?! Personally I would
> like to use the Fulcrum components instead of Turbine components ... :-)
>
> Cheers,
>
> Siegfried Goeschl
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-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