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>