[EMAIL PROTECTED] wrote:
>
> > > I would also like to ask for something like: if a project is using a
> > > component, and none of the project commiters are commiters for the
> > > component - the project as a whole should count as a commiter (
> > > i.e. should be able to request a temporary freeze, a tag, etc - so a
> > > "stable"/"predictible" version of the component can be included ).
> > > ( it that's not too much )
>
> There are 2 issues:
>
> 1. A project should be able to share some code/components. I don't see
> myself using or participating in a library that is not open to all
> jakarta projects. And please don't call it library if the books are going
> to be selected by "library commiters".
1) I never called it a *library*. That got stuck on by Ted et al. I
wanted to call it 'Rupert', as there should be no preconcieved notions
with that name. Apologies to anyone named 'Rupert' by the way. I would
use 'Geir', but no one can pronounce it... :)
2) Why wouldn't you use it? If the stuff is good, and the APIs stable,
you would ignore it because, for example, Velocity (whose core has
*nothing* to do with databases...) as a project doesn't have the right
to veto a move by the DB Connection Pool group to do <FOO> ?
> Yes, you may have duplication - but
> that's far better than having any group of people deciding what is the
> "right" way. I don't care how "expert" or good is the group that makes
> the selection - the library should be open to all jakarta projects
> that want to share something, and the users should decide for themself
> what to read.
Ok. This is true if it's a library in the classical sense. That's not
what I was looking for.
And why? Every other project with a scope and focus has a group
deciding the 'right way'. Tomcat has a group deciding the 'right way'.
I guess, to follow the library analogy, a library still contains
individual books, that have been edited, published, and then selected by
the library. It's not like the general public stocks the shelves
themselves....
>
> 2. If a component is going to be shared, and more than a jakarta project
> is going to use it - I would like all projects that are using the
> component to have at least the right to tag the workspace and veto/fork if
> a change is braking their code. Personally, I will not use a component in
> tomcat if that component is going to change without any control from
> tomcat - I would rather rewrite the component than risk the stability of
> the project and the release.
You can do that - if things really change, and you as a big user aren't
getting listened to, and your needs aren't being met - then take the
code and run. Why is this so different than the normal way of life?
> If a project is preparing for a release - it should be sure that it have
> stable components to use ( even if he's not involved in writing the
> components ).
Sure - just like I assume that tomcat is written to the released
(stable) servlet spec, the released (stable) JDK, etc.
- so if Tomcat uses the Jakarta Flargh component, specify the release
version. A project should make available release versions for users.
> Those are different items. I have no intention to participate in a
> "closed" library ( neither as writer nor reader ).
>
> I think (2) would do a lot in encouraging projects to use the library, but
> it's not that important for me ( well, as a tomcat commiter I would -1
> using a component that may change in the middle of a release without any
> way to control that from tomcat side - but other projects may want to take
> the risk ).
Again, why? Why not just specify the version of the released component
that you are using, and you are no longer at risk as long as that
version is still offered as a complete jar (or source jar, or
whatever...)
which could be required of the projects.
> > * This could result in a groady mess - if any 'regular Jakarta project'
> > can at any time for any reason start another 'library sub-project', then
> > there is *nothing* that compels people to work together.
>
> Any regular jakarta project can create code that is reusable - the library
> commiters don't have any monopoly on reusable code.
Right - true - but what I was looking for is a place for that resuable
code could be presented as such. I know that Turbine has a DBCP. But
it's not really clear. It's not clear how to use it. There are no
"Here's how you use the Turbine connection pool..." docs. There are no
usage examples of the Turbine connection pool, other than Turbine - and
if I am a casual user looking for a componet, why dig out of a framework
that offers no promises?
> And if a projects wants to share this code - I think the library is the
> right place, and the library commiters don't have a monopoly on "the right
> way to do a component" - only users can decide if they want to use a piece
> of code or not.
Of course only users decide. How could you even imagine forcing that?
And if a project wants to share, great. If there is something already
there that does the same thing that is documented and supported and ...
If another project had something to contribute to improve it, or make it
useful for someone else, that's another thing - it should be welcomed
and included. But ad-hoc creation of duplicate projects, or ad-hoc veto
power to arbitrary users should be contrained. I mean, Jakarta has only
one tomcat... I can't imagine Jakarta allowing another servlet container
project to start...
>
> > * This last suggestion promotes a project using a component from the
> > role of user to a 'default committer status' with veto power, without
> > any required investment in the project itself ?
>
> Yes - that's exactly what I'm sugesting. I don't think any project will (
> or should ) use a component if it doesn't have at least some control over
> the component.
Really? Will you drop whatever you are doing on Tomcat if *any* user
that uses it has some issue? Or do you carefully consider the issue,
and deal with it based on your charter and the community's interest as a
whole?
>
> > * This dilutes the potential for 'productizing' some of the things
> > present here in Jakarta into packaged, usable compoenents, since nothing
> > prevents 7 connection pools from being in existance.... I fear
> > duplication of effort again...
>
> Nothing should prevent 7 connection pools.
If they all do the same thing? What's the point? I don't get it. The
biggest CVS tree wins? We have 7 now, and no one knows where they are,
or how to use them, or where to find docs, or maybe there aren't docs,
etc, etc.
> If you want to prevent duplication you should make sure that every project
> feels it's better ( for the project goals ) to use the existing connection
> pool instead of writing another one.
YES. And I would hope that oversight by first the component
user/committer community, the 'Library-ubercommittee' or ultimately the
PMC, should help take care of that. Because if not, any project is free
to make as part of their project a connection pool, document it,
advertise it. Nothing will ever stop that.
Again : my hope was to bring together, for a given component, all the
projects that currently have implemented that component, and see if we
can find a common ground where a useful, sharable, and properly packaged
edition of that component can be offered for general use.
I have a feeling what we are each looking for doesn't share a large
enough basis set to make us both happy... alas...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
