[EMAIL PROTECTED] wrote:
>
> > >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 ?
> >
> > I assumed there was some turbine developers on this list ;) If not is there
> > some struts developers ? It may be good for people to say where they will
> > be able to help migrate in code. I am involved with both Aalon and Ant and
> > will be happy to do what is appropriate to facilitate sharing between these
> > two and this library project.
>
> My point was that the decision should come from a project that wants to
> share a piece of code ( or use a shared component ) - and they shouldn't
> have to be "aproved" by a library comitee.
I don't understand the model you have. No one is forced to do anything.
> I'm a tomcat commiter, but I can't decide on my own to take a piece of
> tomcat, change it, put it in the library and then change
> tomcat to use the library. It should be a decision on tomcat-dev, and the
> people who vote +1 on it and are doing the work of refactoring the
> component for inclusion should be able to maintain in the new repository.
That's right. But then with your model of user-gets-auto-veto, would it
be right that Velocity, which for example would just use the code and
not participate in the development, can basically interfere with the
development evolution of the component that Tomcat is dependent upon?
I agree that only tomcat-dev can decide on how to change tomcat to use
components in the library. And if there is a piece of tomcat that would
be a good candidate, then by all means someone should organize a bit and
propose adding a new component (which I assume would be waved right in
if it was a new addition), or explaining why the existing one doesn't
work [and then working with the existing group to decide if you add
another, or work on the first to fit...]
[SNIP]
> It's very simple:
>
> 1. We either let each project decide on it's own to share / use, and make
> it as easy as possible to do so.
All projects now have the ability to share in a way thats accessable to
others. Some choose not to, and there are good reasons. There is
defacto sharing, as the code is open to all.
The problem is that *right now* no one wants to own and care for some of
the smaller pieces, like a DB connection pool.
Why is that?
> or
>
> 2. Grab code from projects (selecting by vote which component) or create
> new components, with the goal of creating server-side components for
> projects.
> I don't see any reason (2) can't be done in avalon - after all the goal of
> avalon is exactly that.
>
> I also think there is a need for (1), and if the project we are discussing
> now (the library ) is not doing that, probably we need another project.
>
> Costin
>
>
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
