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 Pugh <ep...@apache.org> on 2003/10/16 13:34:17 UTC

Fulcrum Components being integrated into Turbine 2.4

Hi all,

I wanted to update you on some changes in CVS Head for Turbine and issue a
call for help.  I have noticed quite a few emails floating around about
Intake, and thought I should highlight some of the changes I have made to
Turbine 2.4 with regards to Intake and the Fulcrum component repository.

Part of the focus for Turbine 2.4 [1] is to complete the integration of the
various Fulcrum components into Turbine.  Originally Turbine was written
with lots of embedded services, like security, database access, and of
course Intake.  However, over time this meant that Turbine has developed a
huge list of dependencies, when for many users, they don't need most of
these Services.  In addition, creating and sharing new services required
access to the Turbine core CVS.  This was causing a stagnation in the
proliferation of services for Turbine.

So, as part of Turbine 2.3, the Fulcrum Project [2] was begun and Torque [3]
was spun out of the core Turbine codebase.

Fulcrum was meant to be a project in which various components could be
loaded into Turbine.  This is accomplished via the Avalon [5] component
architecture.  This would allow the core of Turbine to be much smaller,
including by default only those components like Pool, Intake, Localization
in the core download, but allowing other components like DVSL, XML-RPC to be
easily added in.  This would also allow components to be enhanced and
released as part of their own release cycle, versus being tied to Turbine's
release schedule, and also be used in other environments.

While the spin off of Torque was completed in the 2.3 timeframe, the
completion of integrating the Fulcrum components back into the Turbine core
was moved into 2.4.  At this point the following Turbine Services have been
deprecated in favor of the Fulcrum ones:

Localization [4]
The Localization service is now being loaded as an Avalon component.  You
can access it via the Localization pulltool that is part of the Turbine code
base.  There should be no changes required in your code.  Configuration of
the service has changed from TurbineResources.properties files to the
roleConfiguration.xml and componentConfiguration.xml files used by Avalon
components.  Localization in Turbine has been deprecated.

Factory [6]
The Factory services in now being loaded as an Avalon Component.  It is a
prerequisite for Intake.  It has not yet been deprecated in Turbine, but
will soon.

Intake [7]
The Intake service in now loaded as an Avalon component.  It is accessible
by the same Intake pulltool that is part of the Turbine code base, therefore
your code shouldn't change.  It still loads up the same Intake.xml file, but
the configuration is done through the Avalon xml files instead of
TurbineResources.properties.  Intake code in Turbine has been deprecated, so
fixes/enhancements should be applied to the Fulcrum version as well.

Most of the other services have been converted to Avalon components as well.
However they haven't yet been integrated back into the core Turbine
codebase.  Here is where YOU can help.  All the Fulcrum components have some
unit tests, and that is a pattern I wish to continue.  When the Fulcrum
Localization and Intake components were integrated back into Turbine, I
added some unit tests to verify the pull tools still functioned the same.
Using these as models, patches with unit test are very much appreciated.
Some good candidates for people to look at are:  Fulcrum Cache, Pool,
Factory (need to deprecate code in Turbine), Mimetype, and XMLRPC.  Some
components that still need conversion to Fulcrum components are: Turbine
XSLT, Turbine Naming.

While it may seem challenging to make these changes, it really is relatively
simple as we are mostly moving code around, versus wholesale refactoring of
it.  But this will lead to a much slimmer Turbine core, and allow more
Turbine services to be created and shared.  For instance, there is now a
OSWorkflow service for turbine [8] and even an example application
demonstrating OSWorkflow in Turbine with a custom Workflow pull tool! [9].
And hopefully soon a OSUser to Turbine Security adapter.

I resolve to work with anyone who expresses an interest in helping, and will
work to solve any build/integration issues they may face.  And of course to
respond to patchs in a reasonably timely manner!

Yours in completing Turbine 2.4 in less time than 2.3,
Eric Pugh




[1] http://jakarta.apache.org/turbine/turbine-2.4/index.html
[2] http://jakarta.apache.org/turbine/fulcrum/
[3] http://db.apache.org/torque/
[4]
http://jakarta.apache.org/turbine/fulcrum/fulcrum-localization/index.html
[5] http://avalon.apache.org/
[6] http://jakarta.apache.org/turbine/fulcrum/fulcrum-factory/index.html
[7] http://jakarta.apache.org/turbine/fulcrum/fulcrum-intake/index.html
[8] http://jakarta.apache.org/turbine/fulcrum/fulcrum-osworkflow/index.html
[9]
http://jakarta.apache.org/turbine/fulcrum/fulcrum-osworkflow-example/index.h
tml


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org