Update

[Jason van Zyl <jv...@zenplex.com>]

Hi,

Some changes have been going on over the last couple days in the 3.x arena.

1. The TDK is almost back up and running and will soon be available again.
Sam Ruby is trying to get Gump to build the TDK on a nightly basis so
hopefully soon people won't have to wait. Though I don't really like the
idea of a TDK nightly build it seems that many others do so it will come to
pass. Once Sam and Martin get the details sort out the TDK nightly builds
will probably show up with the rest of the nightly bundles.

2. The pipeline has been started in the 3.x code. Dan put in some code that
mimics the the Catalina pipeline and I just added some functionality to test
the mapping of an XML descriptor of a pipeline to its corresponding object
model. This is being done with a mapper that is in the stratum repository:

http://cvs.apache.org/viewcvs/jakarta-turbine-stratum/

So the tests are complete and now I imagine Dan and I will hash out the
details along with anyone else who wants to discuss the issues at hand on
the dev list.

3. As mentioned above the stratum repository is now in part in CVS. The code
required for mapping XML to objects whereby the XML assumed to be in a
'standard' form is in along with tests. Soon Aaron's caching code will be
introduced and a small lifecycle package consisting of a set of interfaces
will be checked in. These interfaces are borrowed directly from the avalon
code in the event that we may one day use more of their feature. At any rate
for something as simple as the lifecycle interfaces I see no point in change
the signatures of the interfaces that have already been defined elsewhere.

I was think of putting a graph package in stratum originally but eventually
put it in the commons. This code was donated by Markus Dahm, the author of
BCEL, and will be used in Fulcrum to resolve dependencies amongst services
using a little dep resolver I whipped up based on the graph package.

I also hope that the introduction of the lifecycle package will allow us to
apply the same pattern to turbine, torque and fulcrum so that they all
behave in the same way WRT to lifecycle processing like starting, stopping,
configuring, etc.

This should also allow us to use Fulcrum and Torque in the 2.x code with
some slight modifications to 2.x.

4. A change log, that is similar to the one we have been trying
painstakingly to keep up to date, has been introduced into the turbine-3
tree by Dan and hopefully this will follow the pattern that has been setup
in Torque (inspired by Geir's excellent change log in Velocity) where all
changes are logged so that people don't have to go slogging through CVS logs
to figure out what's changed.

5. I'm hoping that by checking in the tests for the pipeline mapping before
using the code in the hierarchy proper that we can set a precedent whereby a
test goes in first followed by a discussion and subsequent inclusion in the
hierarchy. The tests are finished so now the details can be hashed out on
the dev list and we can get the ball rolling.

6. Things will more than likely start changing a little more quickly as I
will be getting some paid time to work on some turbine code and Dan has
reached a point where he has some time to.

So we will have to figure out a plan of attack for people using turbine-3 in
production which I know is quite a few now. It would probably be best to see
where people are using turbine-3 and than tag/branch so that people can
protect themselves if they so choose.

That's about it for now. I will try to keep posting these sorts of summaries
to the user list but feel free to ping me if as a user you think another
summary is overdue and I'll try to whip one off.

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Update

[Jason van Zyl <jv...@zenplex.com>]

On 12/31/01 5:34 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:

> Comments inline.
> 
> Jason van Zyl <jv...@zenplex.com> writes:
> 
>> 1. The TDK is almost back up and running and will soon be available again.
>> Sam Ruby is trying to get Gump to build the TDK on a nightly basis so
>> hopefully soon people won't have to wait. Though I don't really like the
>> idea of a TDK nightly build it seems that many others do so it will come to
>> pass. Once Sam and Martin get the details sort out the TDK nightly builds
>> will probably show up with the rest of the nightly bundles.
> 
> I'm glad to see TDK nightlies coming about.

I believe these are going to sources, so I don't think they are going to be
what people are expecting. A fully built, functional TDK. It's something we
can talk about.
 
>> 2. The pipeline has been started in the 3.x code. Dan put in some code that
>> mimics the the Catalina pipeline and I just added some functionality to test
>> the mapping of an XML descriptor of a pipeline to its corresponding object
>> model. This is being done with a mapper that is in the stratum repository:
>> 
>> http://cvs.apache.org/viewcvs/jakarta-turbine-stratum/
>> 
>> So the tests are complete and now I imagine Dan and I will hash out the
>> details along with anyone else who wants to discuss the issues at hand on
>> the dev list.
> 
> The Mapper code look good, Jason.  The only issue I noticed was that
> the plural stemmer is heavily tied to Latin-based languages (and
> English in particular).  I suggest a way of overriding the plural
> stemmer (to unconditionally indicate whether your XO markup refers to
> one or many).

We can definitely move it away from being anglo-centric, as a starter I just
wanted to try and have a simple format that can be used for all mappings. I
guess there are some standard mappings like JDO but to me JDO looks a little
over the top.

 > To give credit, the Pipeline/Valve code was lifted directly from
> Catalina, then modified to better suite us in Turbine land.
> 
>> 3. As mentioned above the stratum repository is now in part in CVS. The code
>> required for mapping XML to objects whereby the XML assumed to be in a
>> 'standard' form is in along with tests. Soon Aaron's caching code will be
>> introduced and a small lifecycle package consisting of a set of interfaces
>> will be checked in. These interfaces are borrowed directly from the avalon
>> code in the event that we may one day use more of their feature. At any rate
>> for something as simple as the lifecycle interfaces I see no point in change
>> the signatures of the interfaces that have already been defined elsewhere.
> 
> Let's make sure to use getResourceAsStream() as appropriate to search
> to the classpath for the XML configuration file (as opposed to
> assuming we always load from the classpath).  I would like to see the
> requirement of running Turbine as an unpacked WAR go away.

I just mentioned in another post about getting the resource package in
stratum so that all resources can be dealt with in a uniform fashion and as
it is based on the resource package in velocity we will be able to handle
filesystems and classpaths easily. I would definitely like to hook in the
use the resource package into the mapper.
 
>> I was think of putting a graph package in stratum originally but eventually
>> put it in the commons. This code was donated by Markus Dahm, the author of
>> BCEL, and will be used in Fulcrum to resolve dependencies amongst services
>> using a little dep resolver I whipped up based on the graph package.
> 
> +1 on having the graph package in the Commons.
> 
>> I also hope that the introduction of the lifecycle package will allow us to
>> apply the same pattern to turbine, torque and fulcrum so that they all
>> behave in the same way WRT to lifecycle processing like starting, stopping,
>> configuring, etc.
>> 
>> This should also allow us to use Fulcrum and Torque in the 2.x code with
>> some slight modifications to 2.x.
> 
> This will be great -- looking forward to it.
> 
>> 4. A change log, that is similar to the one we have been trying
>> painstakingly to keep up to date, has been introduced into the turbine-3
>> tree by Dan and hopefully this will follow the pattern that has been setup
>> in Torque (inspired by Geir's excellent change log in Velocity) where all
>> changes are logged so that people don't have to go slogging through CVS logs
>> to figure out what's changed.
> 
> I didn't include my recent fix to the ModuleLoader, on the logic that
> until we release Turbine 3 there isn't a good reason to record bug
> fixes to functionality which is expected to work.  I'm not attached to
> this pattern, however, so if someone would like to take responsibility
> for recording the bug fixes, be my guest.

For now, I think changes in functionality are fine until we release.
 
>> 5. I'm hoping that by checking in the tests for the pipeline mapping before
>> using the code in the hierarchy proper that we can set a precedent whereby a
>> test goes in first followed by a discussion and subsequent inclusion in the
>> hierarchy. The tests are finished so now the details can be hashed out on
>> the dev list and we can get the ball rolling.
> 
> I'll put together some JUnit tests for the Pipeline too so we can avoid
> regressions when making changes in the future.

Fantastic!

> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Update

[Daniel Rall <dl...@finemaltcoding.com>]

Comments inline.

Jason van Zyl <jv...@zenplex.com> writes:

> 1. The TDK is almost back up and running and will soon be available again.
> Sam Ruby is trying to get Gump to build the TDK on a nightly basis so
> hopefully soon people won't have to wait. Though I don't really like the
> idea of a TDK nightly build it seems that many others do so it will come to
> pass. Once Sam and Martin get the details sort out the TDK nightly builds
> will probably show up with the rest of the nightly bundles.

I'm glad to see TDK nightlies coming about.

> 2. The pipeline has been started in the 3.x code. Dan put in some code that
> mimics the the Catalina pipeline and I just added some functionality to test
> the mapping of an XML descriptor of a pipeline to its corresponding object
> model. This is being done with a mapper that is in the stratum repository:
>
> http://cvs.apache.org/viewcvs/jakarta-turbine-stratum/
>
> So the tests are complete and now I imagine Dan and I will hash out the
> details along with anyone else who wants to discuss the issues at hand on
> the dev list.

The Mapper code look good, Jason.  The only issue I noticed was that
the plural stemmer is heavily tied to Latin-based languages (and
English in particular).  I suggest a way of overriding the plural
stemmer (to unconditionally indicate whether your XO markup refers to
one or many).

To give credit, the Pipeline/Valve code was lifted directly from
Catalina, then modified to better suite us in Turbine land.

> 3. As mentioned above the stratum repository is now in part in CVS. The code
> required for mapping XML to objects whereby the XML assumed to be in a
> 'standard' form is in along with tests. Soon Aaron's caching code will be
> introduced and a small lifecycle package consisting of a set of interfaces
> will be checked in. These interfaces are borrowed directly from the avalon
> code in the event that we may one day use more of their feature. At any rate
> for something as simple as the lifecycle interfaces I see no point in change
> the signatures of the interfaces that have already been defined elsewhere.

Let's make sure to use getResourceAsStream() as appropriate to search
to the classpath for the XML configuration file (as opposed to
assuming we always load from the classpath).  I would like to see the
requirement of running Turbine as an unpacked WAR go away.

> I was think of putting a graph package in stratum originally but eventually
> put it in the commons. This code was donated by Markus Dahm, the author of
> BCEL, and will be used in Fulcrum to resolve dependencies amongst services
> using a little dep resolver I whipped up based on the graph package.

+1 on having the graph package in the Commons.

> I also hope that the introduction of the lifecycle package will allow us to
> apply the same pattern to turbine, torque and fulcrum so that they all
> behave in the same way WRT to lifecycle processing like starting, stopping,
> configuring, etc.
>
> This should also allow us to use Fulcrum and Torque in the 2.x code with
> some slight modifications to 2.x.

This will be great -- looking forward to it.

> 4. A change log, that is similar to the one we have been trying
> painstakingly to keep up to date, has been introduced into the turbine-3
> tree by Dan and hopefully this will follow the pattern that has been setup
> in Torque (inspired by Geir's excellent change log in Velocity) where all
> changes are logged so that people don't have to go slogging through CVS logs
> to figure out what's changed.

I didn't include my recent fix to the ModuleLoader, on the logic that
until we release Turbine 3 there isn't a good reason to record bug
fixes to functionality which is expected to work.  I'm not attached to
this pattern, however, so if someone would like to take responsibility
for recording the bug fixes, be my guest.

> 5. I'm hoping that by checking in the tests for the pipeline mapping before
> using the code in the hierarchy proper that we can set a precedent whereby a
> test goes in first followed by a discussion and subsequent inclusion in the
> hierarchy. The tests are finished so now the details can be hashed out on
> the dev list and we can get the ball rolling.

I'll put together some JUnit tests for the Pipeline to we can avoid
regressions when making changes in the future.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>