Peter Donald wrote:

> A few days ago I indicated the 4 paths I saw were
> 
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
> 4. gathering
> 
> (3) is easily doable within current apache model. I believe Costin wants to
> work in (1) and Avalon covers enough of (2) that I don't see it worth
> creating a new project for. So what am I saying? ;) I am +1 for all but (2)
> which I am -1 on at the moment.

Except that Avalon doesn't appear to be a 'catalog' of separate,
independant components that are individually documented, buildable,
etc...  That's what I have in mind for (2), which I am +1 on.  I am also
+0 on (1) [as time is precious these days, and I want to get a *great*
DBCP developed and componentized - there is movement afoot in
Turbine-land for a JDBC compliant component, and Struts is pretty much
there...], +0 on (3) [same reason - no time - but a good idea], and I
don't know what (4) is...

Can we change the name of this list to 'catalog-dev' ?  :)

 
> >From what I gathered our plan of attack was (1). ie Our first module would
> be the DBPool. We would extract it from somewhere (say turbine) refactor
> it. Then push it back into turbine with a wrapper that integrates it into
> the turbine framework. We would then try to integrate it into struts and
> anyone else that uses DB pools. Then we would pick another component and do
> the same. Have I got this correct/wrong?

It might be easier to start with what Struts has is you are in the mood
for JDBC compliant interfaces, but there is lots of discussion going on
in Turbine-land about this.  It's a great time to do this...

geir

-- 
Geir Magnusson Jr.                               [EMAIL PROTECTED]

Developing for the web?  See http://jakarta.apache.org/velocity/

Reply via email to