You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Siegfried Goeschl <si...@it20one.at> on 2005/02/17 11:33:12 UTC
The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Hi Aaron,
1) Original Motivation for YAAFI
1.1) A few months ago I worked on a JSP/Struts web application for a
customer and they needed to integrate a few external services over the
time. I decided to go with Avalon components but I got frustrated with
the various containers (Excalibur, Merlin), my inability to get them
running and the amount of additional dependencies. The problem was not
my frustration as external consultant (I get paid for that) but my
customer would have plainly recjected the Avalon approach if adds too
much complexity (they devil you don't know). To cover my a** I coded a
minimal Avalon container over night.
1.2) In my own company we have a Turbine application and a few services
which could have been contributed years ago but the Turbine Service
Framework is convoluted due to the monolithic approach of Turbine. We
found out that the only stuff we used from Turbine were a few services
and our own stuff. And we are sort of stuck to an old version of Turbine
- well, not a big deal but we would have to migrate our own services. Or
we take the Fulcrum approach which would fit nicely ....
1.3) After another failure with Merlin I decided to go with Avalon
services and my minimal Avalon container. I contacted Eric Pugh if my
quick-and-dirty implementation would be of interest. And I was plainly
astonished that he said "yes"?!!
2) The Role of an Avalon Container
In my opinion the various Avalon projects were mainly focused on the
container implementation. We all love the toys were are implementing but
for the rest of the world an Avalon container is a commodity. Nothing
else - a tool to get a job done. An added value are the available
services with test cases, documentation and automatic build. An Avalon
container with a bunch of good services is a much better tool to get a
job done ... :-)
There is no "container to rule them all" - therefore YAAFI is per
definition a plain and simple AvalonContainer. Writing YAAFI initially
was a sort of personal requirement (to put it politely) but extending
YAAFI to compete with Fortress or Phoenix is a no-brainer. This will not
happen.
3) The Current State of YAAFI
I will finish the contract context thingie tommorrow - then it should be
possible to run any Avalon component with YAAFI. And yes, YAAFI is used
in production environment at least in our company. I think Eric Pugh
tinkered with Scarab - anyone else out there?!
And after proper integration with Turbine there will be more production
environments.
4) The Future of Jakarta Avalon Containers
I see YAAFI as an approiate choice for command-line applications, small
server applications and embedded Avalon container for Turbine and if you
need more bells and whistle you still have other choices - you name them.
And I would appreciate some sort of cross-project cooperation to achieve
the following long-term goals
+) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
run with Fortress and YAAFI
+) promote Fulcrum as an Avalon Service project out of obscurity
+) convince the Excalibur community that YAAFI is not an odd project of
a lone hacker (which it is) to be ignored but as starting point to
migrate over to Fortress
5) The Usual Disclaimer
This is strictly my personal opinion since I have no idea what the rest
of the community is thinking ( "They smoked and did inhale", "Avalon is
dead", "Lets get rid of IOC Type 1 containers", "That was good book",
...) and I'm only a small committer. Maybe the Turbine/Fulcrum PMCs can
shed some light on plans for the future .... hint, hint.
Cheers,
Siegfried Goeschl
J Aaron Farr wrote:
>On Wed, 16 Feb 2005 09:44:18 +0100, Siegfried Goeschl
><si...@it20one.at> wrote:
>
>
>
>>The usage szenario would be : you find a few funky Fulcrum services but
>>they depend on a Merlin Avalon contract regarding the Context. If I
>>understand it correctly you can't use the components directly since the
>>blow up during contextialize() trying to access "urn:avalon:home" and
>>"urn:avalon:temp".
>>
>>
>
>First off, we (Excalibur) need to fix up the context contracts. It
>should be much easier now that Avalon has disolved. If nothing else,
>we could look at having Fortress handle all previous context
>"standards".
>
>
>
>>We have the same requirement for Turbine - if the Turbine service
>>framework does not find a service it should ask all its children
>>implementing ServiceManager. In this case it is not a big deal since
>>this is the only sensible solution to provide container-transparent
>>access to components. But in Excalibur land it has a rather akward semantic.
>>
>>
>
>Sounds like it would involve a change to the default ServiceManager or
>a new ServiceManager implementation.
>
>Siegfried, what was the original motivation for YAAFI? Was it the
>existance of multiple Avalon containers? Was it the number of jar
>dependencies? Is YAAFI intended to be used in a production
>environment?
>
>I'd like to see Fortress evolve to be simple enough that there
>wouldn't be a need for Yet Another Avalon Framework Implementation.
>Maybe Turbine's needs can help drive that.
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
I'm not a Turbine comitter, but. Fulcrum shouldn't be tied to any particular framework or even the servlet api.
There are no advantages doing otherwise !
-- you can stop reading this message here --
On Xingu I have glue code called Esqueleto (skeleton in english) wich is responsible for joining the components (Xingu, Fulcrum, etc) to the framework you want. Only Turbine is working at the moment.
So, one could make something like this :
1) Install your favorite framework (Turbine in this case)
2) cd $ESQUELETO_HOME ; make turbine-base-app (or something else)
3) Edit the configuration files to include/exclude the components you want (Xingu, Fulcrum, etc)
Done. There are a set of actions/screens/templates/tools to handle common tasks such as user administration, security, etc !
OBS: CSS and a skin tool plays a central role here !
That's what I'd like to achieve !
Cheers !
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e
Serviços (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sf.net
On Thu, 17 Feb 2005 18:52:04 -0500, J Aaron Farr <ja...@gmail.com> escreveu:
> De: J Aaron Farr <ja...@gmail.com>
> Data: Thu, 17 Feb 2005 18:52:04 -0500
> Para: Excalibur Developers List <de...@excalibur.apache.org>
> Assunto: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
>
> Thanks for the clarifications. I'm very interested in seeing what
> Excalibur can do to make things easier for the Turbine folks.
>
> > I agree. You should be able to setup a container in a matter of minutes.
> > It should be simple to make simple things.
>
> Exactly.
>
> IMHO Fortress is pretty simply already, but we need better
> documentation and we can definitely make it more simple. The goal of
> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
> So, if I'm reading this correctly, Fulcrum will become a more generic
> component library not necessarily tied to Turbine, right?
>
> --
> jaaron
>
> ---------------------------------------------------------------------
> 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: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
I'm not a Turbine comitter, but. Fulcrum shouldn't be tied to any particular framework or even the servlet api.
There are no advantages doing otherwise !
-- you can stop reading this message here --
On Xingu I have glue code called Esqueleto (skeleton in english) wich is responsible for joining the components (Xingu, Fulcrum, etc) to the framework you want. Only Turbine is working at the moment.
So, one could make something like this :
1) Install your favorite framework (Turbine in this case)
2) cd $ESQUELETO_HOME ; make turbine-base-app (or something else)
3) Edit the configuration files to include/exclude the components you want (Xingu, Fulcrum, etc)
Done. There are a set of actions/screens/templates/tools to handle common tasks such as user administration, security, etc !
OBS: CSS and a skin tool plays a central role here !
That's what I'd like to achieve !
Cheers !
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e
Serviços (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sf.net
On Thu, 17 Feb 2005 18:52:04 -0500, J Aaron Farr <ja...@gmail.com> escreveu:
> De: J Aaron Farr <ja...@gmail.com>
> Data: Thu, 17 Feb 2005 18:52:04 -0500
> Para: Excalibur Developers List <de...@excalibur.apache.org>
> Assunto: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
>
> Thanks for the clarifications. I'm very interested in seeing what
> Excalibur can do to make things easier for the Turbine folks.
>
> > I agree. You should be able to setup a container in a matter of minutes.
> > It should be simple to make simple things.
>
> Exactly.
>
> IMHO Fortress is pretty simply already, but we need better
> documentation and we can definitely make it more simple. The goal of
> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
> So, if I'm reading this correctly, Fulcrum will become a more generic
> component library not necessarily tied to Turbine, right?
>
> --
> jaaron
>
> ---------------------------------------------------------------------
> 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: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 February 2005 18:01, Siegfried Goeschl wrote:
> Hi Aron,
>
> I would like to point out that there is the James project suffering
> badly from the Avalonic wars (hence the cross-posting to the James
> Developer List). They recently had a long discussion to make an
> Avalon-free JamesNG
> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
> feeling is that it won't be an easy task.
A previous discussion led to the conclusion that all configuration and
deployment files must be interpreted as they are now, which leads to an
immense compatibility issue, since you effectively need to be Phoenix/Loom
compatible in every respect.
Now, perhaps such ambitions drop over time, but if not, then I think that
either James resurrects Phoenix as their own internal container (much like
Cocoon now have their own ECM+) or a migration to Loom are the only
reasonable paths forward.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 February 2005 18:01, Siegfried Goeschl wrote:
> Hi Aron,
>
> I would like to point out that there is the James project suffering
> badly from the Avalonic wars (hence the cross-posting to the James
> Developer List). They recently had a long discussion to make an
> Avalon-free JamesNG
> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
> feeling is that it won't be an easy task.
A previous discussion led to the conclusion that all configuration and
deployment files must be interpreted as they are now, which leads to an
immense compatibility issue, since you effectively need to be Phoenix/Loom
compatible in every respect.
Now, perhaps such ambitions drop over time, but if not, then I think that
either James resurrects Phoenix as their own internal container (much like
Cocoon now have their own ECM+) or a migration to Loom are the only
reasonable paths forward.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum
release ....
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I am currently working on removing avalon dependence from current v2x
> source of james and making james a set of POJOs
> And I guess by the end of the following week it will be ready to be
> testable by other developers
Glad to hear that :).
We can't wait to test it :).
>> *) stick with Phoenix or migrate to Loom
>> *) make a transition to Fortress to stay under an ASF umbrella
>> *) jump-start an Avalon-free JamesNG and use an Avalon container of
>> there choice for the migration process
>> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
>
> I vote for the last one
> + reuse components already written by making them POJOs
Sometimes extreme measures are the best to clean something. Maybe if
other software projects would follow your pattern, it wouldn't be so
much "bloatware" out there :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum
release ....
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Siegfried Goeschl wrote:
> Hi Alexander,
>
> it is none of my business but it means that you have to migrate the
> cornerstone and excalibur-datasource stuff as well?! I also assume that
> you are using a IOC container such as Hivemind or Pico/Nano Container?!
Well my goal is to make james a set of CDI style POJOs
As for datasource stuff i just leave interface dependency
"public MyPOJO(DataSourceStuffInterface ds, OtherDepsHere ...)"
and write dummy implementation of that interface ready to be
junit-tested, launched by developer to test the idea of CDI IoC applied
to james current code.
Same applies to other non-jdbc related interfaces.
If someone wants he can use cornerstone/excalibur implementations of
those interfaces.
My point is to remove ugly configuration code from james and make POJOs
not search its configuration itself but accept dependent components as
parameters in constructor.
Injection of dependent components (the process of configuring) is a
concern of any light-weight container, the exact container (whether it
is hivemind/picocontainer) does not matter for me.
As an example I wrote dumb container (one class few K of code) which is
configured by standard james-config.xml familiar to james users and
developers.
Executive summary: make james a set of POJOs, container does not matter
if you have a set of POJOs
>
> Cheers,
>
> Siegfried Goeschl
>
> Siegfried Goeschl
>
> Alexander Zhukov wrote:
>
>> Siegfried Goeschl wrote:
>>
>>> Hi Aron,
>>>
>>> I would like to point out that there is the James project suffering
>>> badly from the Avalonic wars (hence the cross-posting to the James
>>> Developer List). They recently had a long discussion to make an
>>> Avalon-free JamesNG
>>> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
>>> feeling is that it won't be an easy task.
>>
>>
>> I am currently working on removing avalon dependence from current v2x
>> source of james and making james a set of POJOs
>> And I guess by the end of the following week it will be ready to be
>> testable by other developers
>> Yes you are right the task of throwing out avalon is not easy but its
>> worth the trouble.
>> It took me about two weeks already - I have pop3 and smtp servers
>> running, but not clean enough to show others.
>>
>>
>>> As a casual James user and non-contributor I could imagine a few
>>> ways to go
>>>
>>> *) stick with Phoenix or migrate to Loom
>>> *) make a transition to Fortress to stay under an ASF umbrella
>>> *) jump-start an Avalon-free JamesNG and use an Avalon container of
>>> there choice for the migration process
>>> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big
>>> Bang
>>
>>
>> I vote for the last one
>> + reuse components already written by making them POJOs
>>
>>
>>> I'm not sure what the current mood is - well, my first impression is
>>> that removing Avalon make them very happy :-) - but we have to keep
>>> the James community informed on our on-going work regarding Fortress
>>> and Fulcrum YAAFI.
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>
>>> Maybe the James folks might be interested to hear that
>>>
>>> J Aaron Farr wrote:
>>>
>>>> Thanks for the clarifications. I'm very interested in seeing what
>>>> Excalibur can do to make things easier for the Turbine folks.
>>>>
>>>>
>>>>
>>>>> I agree. You should be able to setup a container in a matter of
>>>>> minutes.
>>>>> It should be simple to make simple things.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Exactly.
>>>>
>>>> IMHO Fortress is pretty simply already, but we need better
>>>> documentation and we can definitely make it more simple. The goal of
>>>> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>>>>
>>>> So, if I'm reading this correctly, Fulcrum will become a more generic
>>>> component library not necessarily tied to Turbine, right?
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum
release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Alexander,
it is none of my business but it means that you have to migrate the
cornerstone and excalibur-datasource stuff as well?! I also assume that
you are using a IOC container such as Hivemind or Pico/Nano Container?!
Cheers,
Siegfried Goeschl
Siegfried Goeschl
Alexander Zhukov wrote:
> Siegfried Goeschl wrote:
>
>> Hi Aron,
>>
>> I would like to point out that there is the James project suffering
>> badly from the Avalonic wars (hence the cross-posting to the James
>> Developer List). They recently had a long discussion to make an
>> Avalon-free JamesNG
>> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
>> feeling is that it won't be an easy task.
>
> I am currently working on removing avalon dependence from current v2x
> source of james and making james a set of POJOs
> And I guess by the end of the following week it will be ready to be
> testable by other developers
> Yes you are right the task of throwing out avalon is not easy but its
> worth the trouble.
> It took me about two weeks already - I have pop3 and smtp servers
> running, but not clean enough to show others.
>
>
>> As a casual James user and non-contributor I could imagine a few
>> ways to go
>>
>> *) stick with Phoenix or migrate to Loom
>> *) make a transition to Fortress to stay under an ASF umbrella
>> *) jump-start an Avalon-free JamesNG and use an Avalon container of
>> there choice for the migration process
>> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big
>> Bang
>
> I vote for the last one
> + reuse components already written by making them POJOs
>
>
>> I'm not sure what the current mood is - well, my first impression is
>> that removing Avalon make them very happy :-) - but we have to keep
>> the James community informed on our on-going work regarding Fortress
>> and Fulcrum YAAFI.
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>> Maybe the James folks might be interested to hear that
>>
>> J Aaron Farr wrote:
>>
>>> Thanks for the clarifications. I'm very interested in seeing what
>>> Excalibur can do to make things easier for the Turbine folks.
>>>
>>>
>>>
>>>> I agree. You should be able to setup a container in a matter of
>>>> minutes.
>>>> It should be simple to make simple things.
>>>>
>>>
>>>
>>>
>>> Exactly.
>>>
>>> IMHO Fortress is pretty simply already, but we need better
>>> documentation and we can definitely make it more simple. The goal of
>>> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>>>
>>> So, if I'm reading this correctly, Fulcrum will become a more generic
>>> component library not necessarily tied to Turbine, right?
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release
....
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Siegfried Goeschl wrote:
> Hi Aron,
>
> I would like to point out that there is the James project suffering
> badly from the Avalonic wars (hence the cross-posting to the James
> Developer List). They recently had a long discussion to make an
> Avalon-free JamesNG
> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
> feeling is that it won't be an easy task.
I am currently working on removing avalon dependence from current v2x
source of james and making james a set of POJOs
And I guess by the end of the following week it will be ready to be
testable by other developers
Yes you are right the task of throwing out avalon is not easy but its
worth the trouble.
It took me about two weeks already - I have pop3 and smtp servers
running, but not clean enough to show others.
> As a casual James user and non-contributor I could imagine a few ways
> to go
>
> *) stick with Phoenix or migrate to Loom
> *) make a transition to Fortress to stay under an ASF umbrella
> *) jump-start an Avalon-free JamesNG and use an Avalon container of
> there choice for the migration process
> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I vote for the last one
+ reuse components already written by making them POJOs
> I'm not sure what the current mood is - well, my first impression is
> that removing Avalon make them very happy :-) - but we have to keep the
> James community informed on our on-going work regarding Fortress and
> Fulcrum YAAFI.
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Maybe the James folks might be interested to hear that
>
> J Aaron Farr wrote:
>
>> Thanks for the clarifications. I'm very interested in seeing what
>> Excalibur can do to make things easier for the Turbine folks.
>>
>>
>>
>>> I agree. You should be able to setup a container in a matter of minutes.
>>> It should be simple to make simple things.
>>>
>>
>>
>> Exactly.
>>
>> IMHO Fortress is pretty simply already, but we need better
>> documentation and we can definitely make it more simple. The goal of
>> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>>
>> So, if I'm reading this correctly, Fulcrum will become a more generic
>> component library not necessarily tied to Turbine, right?
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aron,
I would like to point out that there is the James project suffering
badly from the Avalonic wars (hence the cross-posting to the James
Developer List). They recently had a long discussion to make an
Avalon-free JamesNG
(http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
feeling is that it won't be an easy task.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of
there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I'm not sure what the current mood is - well, my first impression is
that removing Avalon make them very happy :-) - but we have to keep the
James community informed on our on-going work regarding Fortress and
Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
>Thanks for the clarifications. I'm very interested in seeing what
>Excalibur can do to make things easier for the Turbine folks.
>
>
>
>>I agree. You should be able to setup a container in a matter of minutes.
>>It should be simple to make simple things.
>>
>>
>
>Exactly.
>
>IMHO Fortress is pretty simply already, but we need better
>documentation and we can definitely make it more simple. The goal of
>Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
>So, if I'm reading this correctly, Fulcrum will become a more generic
>component library not necessarily tied to Turbine, right?
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aron,
I would like to point out that there is the James project suffering
badly from the Avalonic wars (hence the cross-posting to the James
Developer List). They recently had a long discussion to make an
Avalon-free JamesNG
(http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
feeling is that it won't be an easy task.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of
there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I'm not sure what the current mood is - well, my first impression is
that removing Avalon make them very happy :-) - but we have to keep the
James community informed on our on-going work regarding Fortress and
Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
>Thanks for the clarifications. I'm very interested in seeing what
>Excalibur can do to make things easier for the Turbine folks.
>
>
>
>>I agree. You should be able to setup a container in a matter of minutes.
>>It should be simple to make simple things.
>>
>>
>
>Exactly.
>
>IMHO Fortress is pretty simply already, but we need better
>documentation and we can definitely make it more simple. The goal of
>Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
>So, if I'm reading this correctly, Fulcrum will become a more generic
>component library not necessarily tied to Turbine, right?
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
On Fri, 18 Feb 2005 00:54:54 +0100, Eric Pugh
<ep...@www.opensourceconnections.com> wrote:
> I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
> it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
> and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
> swapping to that.
Unless I'm completely out of the loop, there is no release plan for
Fortress 2.0 yet. Heck, we barely have a set of requirements. :)
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
On Fri, 18 Feb 2005 00:54:54 +0100, Eric Pugh
<ep...@www.opensourceconnections.com> wrote:
> I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
> it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
> and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
> swapping to that.
Unless I'm completely out of the loop, there is no release plan for
Fortress 2.0 yet. Heck, we barely have a set of requirements. :)
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leo Simons <ma...@leosimons.com>.
Hi everyone,
On 18-02-2005 00:54, "Eric Pugh" <ep...@www.opensourceconnections.com>
wrote:
> I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
> it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
> and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
> swapping to that.
"Fortress 2" is more the general idea that exists around here that we have
some stuff to document, some things to clean up, some features to implement.
Or maybe that should read "a lot of stuff". It's clear that there's work to
be done.
None of that is written down anywhere central, there's no roadmap or
development plan, or anything like that. You know what these things are
like. If someone gets an itch and gets to work, there /could/ be a
revolutionised release in a few months. It might also be years. But I
wouldn't wait for it.
I suggest you don't actually shoot ECM (it's almost dead already, save the
iron). I haven't looked at Yaafi, but if that is what works for you now, I'd
suggest moving forward with it. As long as your aware of what things to be
weary of (and that seems to be the case), phasing Yaafi out later should be
doable, if you want to.
Best regards,
- Leo Simons
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@www.opensourceconnections.com>.
You are correct about Fulcrum will become a more generic component library.
Although actually, at this time, I would be quite happy in declaring that it
IS a component library not tied to Turbine.
None of the released components depend on Turbine at all, though of course,
due to their heritage, they are primarily used with Turbine. Some of the
unreleased components are somewhat Turbine specific, such as template, and may
have limited utility. They may end up moving to the jakarta-turbine-2 code
base.
The idea is that any component that needs turbine should be IN the Turbine
codebase, with an org.apache.turbine package. Org.apache.fulcrum really
should be completely reusable outside of Turbine.
I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
swapping to that.
Eric
On Thu, 17 Feb 2005 18:52:04 -0500, J Aaron Farr wrote
> Thanks for the clarifications. I'm very interested in seeing what
> Excalibur can do to make things easier for the Turbine folks.
>
> > I agree. You should be able to setup a container in a matter of minutes.
> > It should be simple to make simple things.
>
> Exactly.
>
> IMHO Fortress is pretty simply already, but we need better
> documentation and we can definitely make it more simple. The goal of
> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
> So, if I'm reading this correctly, Fulcrum will become a more generic
> component library not necessarily tied to Turbine, right?
>
> --
> jaaron
>
> ---------------------------------------------------------------------
> 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: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aron,
I would like to point out that there is the James project suffering
badly from the Avalonic wars (hence the cross-posting to the James
Developer List). They recently had a long discussion to make an
Avalon-free JamesNG
(http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
feeling is that it won't be an easy task.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of
there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I'm not sure what the current mood is - well, my first impression is
that removing Avalon make them very happy :-) - but we have to keep the
James community informed on our on-going work regarding Fortress and
Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
>Thanks for the clarifications. I'm very interested in seeing what
>Excalibur can do to make things easier for the Turbine folks.
>
>
>
>>I agree. You should be able to setup a container in a matter of minutes.
>>It should be simple to make simple things.
>>
>>
>
>Exactly.
>
>IMHO Fortress is pretty simply already, but we need better
>documentation and we can definitely make it more simple. The goal of
>Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
>So, if I'm reading this correctly, Fulcrum will become a more generic
>component library not necessarily tied to Turbine, right?
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
Thanks for the clarifications. I'm very interested in seeing what
Excalibur can do to make things easier for the Turbine folks.
> I agree. You should be able to setup a container in a matter of minutes.
> It should be simple to make simple things.
Exactly.
IMHO Fortress is pretty simply already, but we need better
documentation and we can definitely make it more simple. The goal of
Fortress 2.0 should be to make implementations like yaafi unnecessary.
So, if I'm reading this correctly, Fulcrum will become a more generic
component library not necessarily tied to Turbine, right?
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
Thanks for the clarifications. I'm very interested in seeing what
Excalibur can do to make things easier for the Turbine folks.
> I agree. You should be able to setup a container in a matter of minutes.
> It should be simple to make simple things.
Exactly.
IMHO Fortress is pretty simply already, but we need better
documentation and we can definitely make it more simple. The goal of
Fortress 2.0 should be to make implementations like yaafi unnecessary.
So, if I'm reading this correctly, Fulcrum will become a more generic
component library not necessarily tied to Turbine, right?
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
RE: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@opensourceconnections.com>.
Leandro's vision of the future for Turbine is very much in line with
what the committers would like to see happen to Turbine. Turbine 2.3
was the beginning of cleaning up the massive mess of code by introducing
the first Avalon container based on ECM and moving Torque to it's own
project. Turbine 2.4 (stil in development) has continued that process.
We continue to use ECM primarily in Turbine, have deprecated many of the
old Turbine services in favor of released components from the Fulcrum
project. Turbine 2.5 (somewhere down the road) will have a very minimal
set of dependencies, and you add the ones you require.
Part of the interest in using Yaafi was that we needed an easy to setup
container for running unit tests. And I liked the idea of having two
containers, Yaafi and ECM, to validate that the Fulcrum components are
really portable.
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Thursday, February 17, 2005 5:35 AM
To: siegfried.goeschl@it20one.at
Cc: Turbine Developers List; Excalibur Developers List
Subject: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release
....
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded
a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few
> services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of
Turbine
> - well, not a big deal but we would have to migrate our own services.
Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to
> achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum,
> +Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
RE: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@opensourceconnections.com>.
Leandro's vision of the future for Turbine is very much in line with
what the committers would like to see happen to Turbine. Turbine 2.3
was the beginning of cleaning up the massive mess of code by introducing
the first Avalon container based on ECM and moving Torque to it's own
project. Turbine 2.4 (stil in development) has continued that process.
We continue to use ECM primarily in Turbine, have deprecated many of the
old Turbine services in favor of released components from the Fulcrum
project. Turbine 2.5 (somewhere down the road) will have a very minimal
set of dependencies, and you add the ones you require.
Part of the interest in using Yaafi was that we needed an easy to setup
container for running unit tests. And I liked the idea of having two
containers, Yaafi and ECM, to validate that the Fulcrum components are
really portable.
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Thursday, February 17, 2005 5:35 AM
To: siegfried.goeschl@it20one.at
Cc: Turbine Developers List; Excalibur Developers List
Subject: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release
....
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded
a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few
> services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of
Turbine
> - well, not a big deal but we would have to migrate our own services.
Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to
> achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum,
> +Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of Turbine
> - well, not a big deal but we would have to migrate our own services. Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of Turbine
> - well, not a big deal but we would have to migrate our own services. Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org