> >> In any case - I hope Ted will include the 2 proposals in the final vote,
> >> and I'll let the majority decide what will be the goal and rules for this
> >> project.
> >
> >As near as I can figure we have already covered that ground, and the
> >current proposal already reflects what the majority of people
> >contributing to this list have decided. 
> 
> I am kinda confused ;)
> 
> 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.

I agree with this.

I am interested in a component repository for the existing code in
projects - where the projects can share the code if they choose to. 

It looks like in the current form, the library is duplicating Avalon -
it's goal is to create productized server-side components, and I don't see
any reason you'll need another project doing the same thing.

All you have to do is contribute code to avalon, like any user, become a
commiter - and then propose new components. I don't see any significant
diference to require a new jakarta project. After all, the project goal
is the same, and everything else is implementation detail ( i.e. how do
you organize the code ) - and if you can propose it to avalon and be voted
by existing avalon commiters. 


> >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?

And why not letting the original authors of a component decide for
themself what to do with a component ? And why not let turbine decide if
they want to share the component and how to do it ? 

What makes you think that whatever DBPool you choose will be better ? And
what makes you think that a project will be happy to replace some code
they developed and serve their purpose with something they have no control
over ? 

Costin



Reply via email to