You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Eric Dobbs <er...@dobbse.net> on 2002/07/26 01:53:39 UTC
[PROPOSAL] Turbine Road Map
Things are a bit confusing right now. We have an incomplete
decoupling of Turbine 2, and our development resources are
spread thin between two versions of Turbine, the old coupled
services, Torque, Maven, and of course our regular jobs.
Those of us in the know are not alarmed about it. But the
general users are not in the loop. I'd like to decide on a
roadmap and loudly publish it so everyone knows what we're
up to.
So here's a proposed roadmap.
Today we have Turbine 2.1.
coupled Torque
coupled Fulcrum
Real soon now we'll have Turbine 2.2
decoupled Torque
coupled Fulcrum
Next step will be Turbine 2.3
decoupled Torque
support for OJB included
coupled Fulcrum and services deprecated (for backward compatibility)
Plexus container for the components
Components migrated from decoupled Fulcrum
other Avalon components can also be used in Turbine and vice
versa
Turbine 3
Security has been decoupled into a separate component
coupled Fulcrum is gone
OJB support continues
Torque support continues
Plexus continues
Components continue
What do you think about these milestones?
-Eric.
ps. A brief primer on Avalon and Plexus.
Avalon has many different containers: Phoenix, Merlin, Fortress,
Tweety, MicroContainer. There may be more. The containers are
responsible for managing the lifecycle of the components they
contain. Plexus is another container. You can get the code
here:
http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
You can look at the Avalon framework to see what the lifecycle
interfaces are about:
http://jakarta.apache.org/avalon/api/index.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Turbine Road Map
Posted by Stephen Haberman <st...@chase3000.com>.
What if instead of going with 2.8 as a mix of old-style Fulcrum services
and new-style Avalon components, we just make T3 support the old-style
Fulcrum services?
Though I agree with James, T3 should not coupled to the old-style
Fulcrum services. All of the internals and services of T3 would be
Avalon, but one of the T3's Avalon components could act as a bridge to
the old-style Fulcrum services (e.g. reading in their configuration from
TurbineResources.properties, init'ing then, etc).
So we could stop with Turbine 2.2, but the development effort behind the
Avalonized T3, but still give users with Fulcrum services a clean (dare
I say seamless?) migration path.
I don't know the specifics of how such a Avalon/Fulcrum bridge would
work, but my naïve impression is that it would be possible.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Turbine Road Map
Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, July 26, 2002, at 03:03 PM, Andris Spruds wrote:
> I agree. In my opinion, Turbine2.3 developement is a waste of time:
> instead
> of migrating from 2.1 to 3 (which, no doubt, WILL involve major code
> rewriting), old poor users will first rewrite part of their code for
> 2.2 (as
> I understand, it won't be 100% backwards compatible), then to Turbine
> 2.3
> and then they will have to drop (nearly) everyhting and start from
> ground
> zero again.
Dropping (nearly) everything?!!. That's exactly
what I'm hoping to /avoid/. We need a migration
path from Turbine 2 to 3. That's going to involve
changing code. I'm proposing milestones to
hopefully make those code changes manageable. The
goal is to minimize the pain of migrating.
> And I don't think there are currently so many custom
> user-written services wich use Fulcrum: most of the work will be to
> rewrite
> major services, such as Template & friends, etc.
I have custom services. And I want a migration
path for them. I'll be surprised if I'm the only
one on this list who has custom services.
I'll add some annotation.
Today we have Turbine 2.1.
coupled Torque
coupled Fulcrum
Real soon now we'll have Turbine 2.2
decoupled Torque
coupled Fulcrum
Here the code changes surround Torque.
Turbine users are going to have to change
Vectors to Lists in their code. And they'll
have to regenerate their object model and
recompile. I understand this only took the
Scarab folks a couple hours. I think that's
it for required code changes.
Next step will be Turbine 2.8 (or something)
decoupled Torque
support for OJB included
coupled Fulcrum and services deprecated (for
backward compatibility)
Plexus container for the components
Components migrated from decoupled Fulcrum
other Avalon components can also be
used in Turbine and vice versa
Turbine users should hopefully not have to
change any of their own code to get their
app running with this version.
Users are expected to begin migrating from
the use of the Fulcrum services to the use
of Plexus components.
A comment about the version number. James
noted that 3.0 should not be coupled to the
Fulcrum services. That leads me to believe
that 3.0 should be reserved for the version
of Turbine in which the decoupling is
complete. That's not the case here, so this
is still a 2.x release. But we need to
indicate a significant change because of the
addition of Plexus. Hence 2.8.
Did I really just spent a whole paragraph on a
version number? 8^{
Turbine 3.0
Security has been decoupled into a separate
component
coupled Fulcrum is gone
OJB support continues
Torque support continues
Plexus continues
Components continue
At this point the decoupling is complete.
Users must have completed the change to
use the Plexus components instead of
Fulcrum in order to upgrade to 3.0.
Hope that helps.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Turbine Road Map
Posted by Andris Spruds <li...@apollo.lv>.
I agree. In my opinion, Turbine2.3 developement is a waste of time: instead
of migrating from 2.1 to 3 (which, no doubt, WILL involve major code
rewriting), old poor users will first rewrite part of their code for 2.2 (as
I understand, it won't be 100% backwards compatible), then to Turbine 2.3
and then they will have to drop (nearly) everyhting and start from ground
zero again. And I don't think there are currently so many custom
user-written services wich use Fulcrum: most of the work will be to rewrite
major services, such as Template & friends, etc.
-Andris Spruds
>>I'm a real newbie at this release cycle stuff, but my naïve suggestion
>>is to skip Turbine 2.3...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Turbine Road Map
Posted by James Taylor <jt...@4lane.com>.
> Next step will be Turbine 3.0
> decoupled Torque
> support for OJB included
> coupled Fulcrum and services deprecated (for backward
> compatibility)
> Plexus container for the components
> Components migrated from decoupled Fulcrum
> other Avalon components can also be used in Turbine and vice
This renumbering seems reasonable to me, however (and you might have
been thinking this, it is not contrary to the above) I would like for
turbine 3 not to depend on anything in fulcrum, even though it will
still be able to init any fulcrum services a users application might
have.
The services T3 owns (Pull, RunData) and depends directly on (the whole
TemplateEngineService clusterfsck, possibly others...) should be recast
as components, or replaced with better mechanisms (particularly in the
case of TES -- we can do better =)
That is what I've been thinking at least, and I _think_ it is mostly
aligned with what Jason wants / needs.
-- jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Turbine Road Map
Posted by Eric Dobbs <er...@dobbse.net>.
On Thursday, July 25, 2002, at 06:09 PM, Stephen Haberman wrote:
> The Avalonized Turbine stuff seems, to me, radical enough to warrant a
> major release, not an update within the 2.x line.
We need time to deprecate the Fulcrum stuff to allow
time for users to migrate to the Plexus stuff. But I
agree that the change is radical enough to justify a
major release. How's this instead (just changing the
numbering):
Today we have Turbine 2.1.
coupled Torque
coupled Fulcrum
Real soon now we'll have Turbine 2.2
decoupled Torque
coupled Fulcrum
Next step will be Turbine 3.0
decoupled Torque
support for OJB included
coupled Fulcrum and services deprecated (for backward
compatibility)
Plexus container for the components
Components migrated from decoupled Fulcrum
other Avalon components can also be used in Turbine and vice
versa
Turbine 3.1
Security has been decoupled into a separate component
coupled Fulcrum is gone
OJB support continues
Torque support continues
Plexus continues
Components continue
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] Turbine Road Map
Posted by Stephen Haberman <st...@chase3000.com>.
I'm a real newbie at this release cycle stuff, but my naïve suggestion
is to skip Turbine 2.3 and all the work it would take to tie Plexus into
the Turbine 2.2 core (I have no clue how much work it would be, perhaps
it would be really easy, I dunno), and instead go from Turbine 2.2 right
into Turbine 3.0 which starts afresh with the
Avalonized/pipeline-enabled design.
The Avalonized Turbine stuff seems, to me, radical enough to warrant a
major release, not an update within the 2.x line.
If the OJB support is really wanted in Turbine 2.x, a 2.2.5/2.3 release
with OJB support would make sense, but I would still think any Plexus
stuff should be pushed off to T3.
- Stephen
> -----Original Message-----
> From: Eric Dobbs [mailto:eric@dobbse.net]
> Sent: Thursday, July 25, 2002 6:54 PM
> To: turbine-dev@jakarta.apache.org
> Subject: [PROPOSAL] Turbine Road Map
>
> Things are a bit confusing right now. We have an incomplete
> decoupling of Turbine 2, and our development resources are
> spread thin between two versions of Turbine, the old coupled
> services, Torque, Maven, and of course our regular jobs.
>
> Those of us in the know are not alarmed about it. But the
> general users are not in the loop. I'd like to decide on a
> roadmap and loudly publish it so everyone knows what we're
> up to.
>
> So here's a proposed roadmap.
>
>
> Today we have Turbine 2.1.
> coupled Torque
> coupled Fulcrum
>
> Real soon now we'll have Turbine 2.2
> decoupled Torque
> coupled Fulcrum
>
> Next step will be Turbine 2.3
> decoupled Torque
> support for OJB included
> coupled Fulcrum and services deprecated (for backward
compatibility)
> Plexus container for the components
> Components migrated from decoupled Fulcrum
> other Avalon components can also be used in Turbine and vice
> versa
>
> Turbine 3
> Security has been decoupled into a separate component
> coupled Fulcrum is gone
> OJB support continues
> Torque support continues
> Plexus continues
> Components continue
>
>
> What do you think about these milestones?
>
> -Eric.
>
> ps. A brief primer on Avalon and Plexus.
> Avalon has many different containers: Phoenix, Merlin, Fortress,
> Tweety, MicroContainer. There may be more. The containers are
> responsible for managing the lifecycle of the components they
> contain. Plexus is another container. You can get the code
> here:
> http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
>
> You can look at the Avalon framework to see what the lifecycle
> interfaces are about:
> http://jakarta.apache.org/avalon/api/index.html
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>