You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Stephen Haberman <st...@beachead.com> on 2003/01/09 08:45:41 UTC
fulcrum short-term
Hi,
Is anyone using Fulcrum HEAD? I can tell the Avalonization has/was
started, what with FulcrumContainer and what not, but is anyone
using it in an Avalon environment (or non-Avalon)? Or is it in a
suspended state?
Basically I'm wondering if I could investigate refactoring things a
bit to be more elegant. E.g. get rid of the old singleton TurbineXxx
classes that just had wrapper methods around the class, move stuff
over to the Avalon lifecycles/configuration, and then get rid of the
rest of the cruft.
I see there is a PRE_AVALON tag...is that enough or are there enough
people needing the old Turbinized Fulcrum that a branch is
warranted?
Oh, and I'd also like, as a part of this, refactor the stratum cruft
out of o.a.torque.Torque and have it be an Avalon component just
like the rest of the Fulcrum stuff. Should be easy, both in
Torque/Fulcrum and then the relevant changes to Turbine-2.2/2.3.
(Also note that my time frame for doing the refactoring is not
within the next few days, but over the next few weeks.)
Thanks,
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Stephen Haberman <st...@beachead.com>.
On Sun, Jan 12, 2003 at 11:13:03AM +0000, Henning P. Schmiedehausen wrote:
> Stephen Haberman <st...@beachead.com> writes:
>
> >Perhaps some of the Maven devs can chip in on how it has been
> >working out for them? It is a lot more directories, but are the
> >perceived benefits worth it?
>
> Try looking for a certain property on
> http://jakarta.apache.org/turbine/maven
>
> Then you would know that it sucks big rocks.
Hehe, good point. What if there were a sort of property/goal/etc.
index for the main (reactor?) project with links into the child
projects?
Would this remove the only detriment or was this just a specific
example out of many for why you dislike the separate project
approach?
Thanks,
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Stephen Haberman <st...@beachead.com> writes:
>Perhaps some of the Maven devs can chip in on how it has been
>working out for them? It is a lot more directories, but are the
>perceived benefits worth it?
Try looking for a certain property on http://jakarta.apache.org/turbine/maven
Then you would know that it sucks big rocks.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Stephen Haberman <st...@beachead.com>.
On Sat, Jan 11, 2003 at 09:44:39PM +0100, Dan Diephouse wrote:
> 2. With the advent of maven, would it make sense to split fulcrum into
> component builds like maven has in its tree? This provides an area for
> documentation of each component. Then if I want to use just intake or
> just the factory service I can. Granted, this is getting pretty fine
> grained. Thoughts?
Hm, cool. I really like the idea of per-service documentation. Plus
per-service isolation for testing, etc.
Perhaps some of the Maven devs can chip in on how it has been
working out for them? It is a lot more directories, but are the
perceived benefits worth it?
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Dan Diephouse <da...@envoisolutions.com>.
Stephen Haberman wrote:
> Hi,
>
> Is anyone using Fulcrum HEAD? I can tell the Avalonization has/was
> started, what with FulcrumContainer and what not, but is anyone
> using it in an Avalon environment (or non-Avalon)? Or is it in a
> suspended state?
Yes, I have been working with it - but it is quite messy at the moment.
> Basically I'm wondering if I could investigate refactoring things a
> bit to be more elegant. E.g. get rid of the old singleton TurbineXxx
> classes that just had wrapper methods around the class, move stuff
> over to the Avalon lifecycles/configuration, and then get rid of the
> rest of the cruft.
Let the refactoring begin!!!
> (Also note that my time frame for doing the refactoring is not
> within the next few days, but over the next few weeks.)
I don't think it would be too hard to do all this. Two thoughts though:
1. Avalon fulcrum support needs to be integrated into the Turbine-3
tree. John McNally: you made the changes to avalonize fulcrum. Did you
have changes to check into the T3 tree also? I filed a bug and posted a
patch, but I don't know if its what people had in mind.
2. With the advent of maven, would it make sense to split fulcrum into
component builds like maven has in its tree? This provides an area for
documentation of each component. Then if I want to use just intake or
just the factory service I can. Granted, this is getting pretty fine
grained. Thoughts?
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Stephen Haberman <st...@beachead.com>.
On Sat, Jan 11, 2003 at 09:52:31AM +0100, Nicola Ken Barozzi wrote:
> After that we will deliver a unified container, and with that we
> will stop enhancing Phoenix and have the one and only Avalon
> container.
Nice! As you probably already realize, having one and only one
Avalon container will be a great boon to adoption, from my
standpoint as a user.
> >Is Fortress to the point where I could get a snapshot/dev release
> >and use it with little trouble (from two aspects, one in Fulcrum
> >e.g. for unit testing and the like, and the other in my app as a
> >server/daemon container)? Or should I wait for the release?
>
> It's almost ready, AFAIK you should be able to use it with no real
> big problem. We are working on the "wrap-up" phase to get it
> released.
Sounds good. Currently Fulcrum is using ECM as it's container, so
I'll spend just a little time seeing how easy it would be to drop in
Fortress (my only concern is the change of meta-data and current
lack of documentation on it for Fortress).
Thanks,
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Haberman wrote:
> On Fri, Jan 10, 2003 at 08:59:34AM +0100, Nicola Ken Barozzi wrote:
>
>>In any case, we will be releasing Fortress quite soon. The best
>>thing is to try and keep the Components as un-tied to a specific
>>container as possible, so that they can be reused by others. That
>>is the route we will take with Cornerstone and Excalibur.
>
>
> I definitely agree with the container-agnostic approach. I've got an
> app I need to get up and running in a container ASAP (we dropped a
> Turbine-3 web frontend in favor of an XML-RPC service), so I'm
> looking at Phoenix and my general understanding is that I can write
> the components with just the framework interfaces (per the
> avalon-apps/demo) to be container-agnostic, but then use some
> container-specific meta data to wrap them together into, in this
> case, blocks to be started by Phoenix.
>
> Will Fortress be along the lines of something I point at components
> and it will start them up as a server daemon type thing? Or is it
> more like ECM, which (as I've gathered from the existing Fulcrum use
> of it) just does component management as a Java object, and would
> have to have some other thread/process create it and the loop until
> it should shutdown?
Fortress is meant to be ECM 2, so it doesn't have the "block" concept.
I'm using it as a daemon in my projects, but with a flat component
management structure.
We are now quite confident that after Fortress release, Merlin and
Fortress will merge completely and make the sort of container you
envision. The important thing here is that we will be releasing and
supporting from now on only one container. So Merlin will be a
replecement and enhancement for Fortress.
After that we will deliver a unified container, and with that we will
stop enhancing Phoenix and have the one and only Avalon container.
Our objective now from a component perspective is the possibility of
complete drop-in portability.
> Is Fortress to the point where I could get a snapshot/dev release
> and use it with little trouble (from two aspects, one in Fulcrum
> e.g. for unit testing and the like, and the other in my app as a
> server/daemon container)? Or should I wait for the release?
It's almost ready, AFAIK you should be able to use it with no real big
problem. We are working on the "wrap-up" phase to get it released.
>>We will create the Avalon Components project I had proposed you
>>some time back. Options are a repository under Avalon that is open
>>to project using them, or one under Apache Commons. In any case,
>>who uses our components in his project extensively could work on
>>the repo. Then we would keep a list of all components using
>>Avalon, Turbine ones included.
>
>
> Sounds great.
>
> Thanks for the input. I'm finally getting my hands on some concrete
> Avalon stuff instead of just speculating about when Turbine will
> become Avalonized, and I'm having fun, it's some very cool
> technology.
Thanks :-)
But technology without the "beef" is useless. That's why we are all
thrilled that Turbine services are being avalonized. I remember that
some years ago we wanted to use Turbine services in Cocoon, but nobody
ever got to doing it. Now that possibility is finally getting real :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Stephen Haberman <st...@beachead.com>.
On Fri, Jan 10, 2003 at 08:59:34AM +0100, Nicola Ken Barozzi wrote:
> In any case, we will be releasing Fortress quite soon. The best
> thing is to try and keep the Components as un-tied to a specific
> container as possible, so that they can be reused by others. That
> is the route we will take with Cornerstone and Excalibur.
I definitely agree with the container-agnostic approach. I've got an
app I need to get up and running in a container ASAP (we dropped a
Turbine-3 web frontend in favor of an XML-RPC service), so I'm
looking at Phoenix and my general understanding is that I can write
the components with just the framework interfaces (per the
avalon-apps/demo) to be container-agnostic, but then use some
container-specific meta data to wrap them together into, in this
case, blocks to be started by Phoenix.
Will Fortress be along the lines of something I point at components
and it will start them up as a server daemon type thing? Or is it
more like ECM, which (as I've gathered from the existing Fulcrum use
of it) just does component management as a Java object, and would
have to have some other thread/process create it and the loop until
it should shutdown?
Is Fortress to the point where I could get a snapshot/dev release
and use it with little trouble (from two aspects, one in Fulcrum
e.g. for unit testing and the like, and the other in my app as a
server/daemon container)? Or should I wait for the release?
> We will create the Avalon Components project I had proposed you
> some time back. Options are a repository under Avalon that is open
> to project using them, or one under Apache Commons. In any case,
> who uses our components in his project extensively could work on
> the repo. Then we would keep a list of all components using
> Avalon, Turbine ones included.
Sounds great.
Thanks for the input. I'm finally getting my hands on some concrete
Avalon stuff instead of just speculating about when Turbine will
become Avalonized, and I'm having fun, it's some very cool
technology.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Haberman wrote:
[...]
> I haven't looked in on Plexus lately...at one point I get the
> impression that Jason was using it to play with Avalon stuff until
> something better came out of Avalon (e.g. Fortress/Merlin). Is this
> still the idea? Or is Turbine/Fulcrum/Torque looking at using
> Plexus as it's primary container?
In any case, we will be releasing Fortress quite soon. The best thing is
to try and keep the Components as un-tied to a specific container as
possible, so that they can be reused by others. That is the route we
will take with Cornerstone and Excalibur.
We will create the Avalon Components project I had proposed you some
time back. Options are a repository under Avalon that is open to project
using them, or one under Apache Commons. In any case, who uses our
components in his project extensively could work on the repo.
Then we would keep a list of all components using Avalon, Turbine ones
included.
What do you think?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Stephen Haberman <st...@beachead.com>.
On Thu, Jan 09, 2003 at 01:09:57PM -0800, Daniel Rall wrote:
> I will be moving SourceCast to the new Avalonized Fulcrum code at the end of
> February. Any service implementations which haven't yet been ported which
> are used by SourceCast (e.g. XML-RPC) I will port at that time.
Cool.
> I'd also be a fan of seeing the TurbineXxx classes go. I'm +1 on
> deprecating them today and removing them in a while. I'm unsure about the
> interface classes -- I suppose that those should probably stay.
Sounds like a good idea.
> The non-Avalon interface to the old-style Fulcrum core which John McNally
> was able to preserve should also stay in the mainline for some time to come.
Okay, so like along with the XML-RPC component, Intake component,
etc., we'll have a LegacyFulcrum component that loads old school
Fulcrum services? I think moving the logic out to its own component
instead of being in the core makes sense...initially, I haven't
thought it all the way through it.
Which brings up the point of the core/container. Fulcrum currently
has the BaseServiceBroker/FulcrumContainer/etc., but I take it we
don't really want for Fulcrum to have it's own container.
Perhaps getting rid of BaseServiceBroker and relying totally on a
wrapped Avalon container (e.g. how FulcrumContainer uses
ECM...though I'd really like to rename FulcrumContainer, as it
insinuates we have our own container. Something more like
ContainerBootstrap or what not) is what I'm thinking and from what I
can tell, is what is done so far, just a little crufty what with the
old BaseServiceBroker and singleton patterns still there.
> I wouldn't be adverse to seeing a branch which dumps that stuff entirely (as
> per Duncan's "Rules for Revolutionaries"), but I think that Jason van Zyl
> has already done a good deal of that work with his own Avalon container
> (Plexus?).
I haven't looked in on Plexus lately...at one point I get the
impression that Jason was using it to play with Avalon stuff until
something better came out of Avalon (e.g. Fortress/Merlin). Is this
still the idea? Or is Turbine/Fulcrum/Torque looking at using
Plexus as it's primary container?
> Woo hoo!! Go Stephen!
Hehe, sounds good. We'll see what I can get around to doing.
Thanks,
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fulcrum short-term
Posted by Daniel Rall <dl...@apache.org>.
On Thu, 9 Jan 2003, Stephen Haberman wrote:
> Is anyone using Fulcrum HEAD? I can tell the Avalonization has/was
> started, what with FulcrumContainer and what not, but is anyone
> using it in an Avalon environment (or non-Avalon)? Or is it in a
> suspended state?
I will be moving SourceCast to the new Avalonized Fulcrum code at the end of
February. Any service implementations which haven't yet been ported which
are used by SourceCast (e.g. XML-RPC) I will port at that time.
> Basically I'm wondering if I could investigate refactoring things a
> bit to be more elegant. E.g. get rid of the old singleton TurbineXxx
> classes that just had wrapper methods around the class, move stuff
> over to the Avalon lifecycles/configuration, and then get rid of the
> rest of the cruft.
I'd also be a fan of seeing the TurbineXxx classes go. I'm +1 on
deprecating them today and removing them in a while. I'm unsure about the
interface classes -- I suppose that those should probably stay.
The non-Avalon interface to the old-style Fulcrum core which John McNally
was able to preserve should also stay in the mainline for some time to come.
I wouldn't be adverse to seeing a branch which dumps that stuff entirely (as
per Duncan's "Rules for Revolutionaries"), but I think that Jason van Zyl
has already done a good deal of that work with his own Avalon container
(Plexus?).
> I see there is a PRE_AVALON tag...is that enough or are there enough
> people needing the old Turbinized Fulcrum that a branch is
> warranted?
I believe that tag exists for those wanting to get at the last
state of the source code pre-Avalon. I don't think that it's a branch tag,
and personally don't yet need such a branch. The only reason I could see
myself needing one is for later maintainence. However, the fact that
Fulcrum doesn't have much in the way of release tags makes this tricky
indeed; it's likely I'll never use such a branch.
> Oh, and I'd also like, as a part of this, refactor the stratum cruft
> out of o.a.torque.Torque and have it be an Avalon component just
> like the rest of the Fulcrum stuff. Should be easy, both in
> Torque/Fulcrum and then the relevant changes to Turbine-2.2/2.3.
Woo hoo!! Go Stephen!
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>