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/
