[EMAIL PROTECTED] wrote:
>
> > > > something rational. Multiple implementations of the same identical
> > > > thing is a waste of talent and time.
> > >
> > > Code doesn't just grow on CVS trees ;-).
> >
> > And the way this is going, there won't be 'trees' plural, just one
> > enourmous one. :)
>
> Geir, you have my vote for multiple CVS trees ( whenever it makes sense
> and/or the commiters working on a component just asks for it ). I also
> agree with you that for a productized components that grows it may be
> better to have separate tree ( and it already happened - I know a little
> tool in jakarta-tools that now has it's own cvs :-)
Why isn't jakarta-tools on the Jakarta site? What is it?
>
> > > In this hypothetical, obviously
> > > somebody thought it was worthwhile, or it wouldn't exist. But, none of
> > > this is anything we can predetermine. When there is an actual codebase
> > > on the table, we can make an actual decision, and have an actual vote.
> >
> > Of course, but I thought the point here is to get the basics
> > straightened out now before we propose.
>
> +1 - I think the basic here is that we can't decide for others or force
> a solution for all cases.
Right - that's my point. If library is functionally a mini-jakarta,
then each project has it's own rules and governance, modulo Jakarta
governance. I neither want nor feel qualified to decide what is best
for your project, anyone's project. I want to set it up so once a
project is off and going, the committers have the control over their
project, just like they do in regular jakarta projects. I don't feel
that what I want to see is in any way innovative or original - just
recognizing that the Jakara model seems to work, that the the
Jakarta/PMC model can only support so much 'width' in its top level
offerings, and this allows us to provide some depth to the project tree.
The best solution, I think, is the most minimal and open one, and as I
see it, the most open one is simply a Jakarta project that acts as a
container for independent Jakarta mini-projects.
* It keeps the load off of the Jakarta PMC everytime someone has
something small and complete to offer to the world that is withing the
scope of Jakarta.
* The Jakarta project governance conventions apply to each mini-project
(via voting, committers, etc.) Nothing new needs to be invented, tested,
etc (unless the mini-project made it a part of their charter, a la
taglibs...)
* It can be a home for boring product mini-projects like a connection
pool.
* It can be a home for Agora
* It can be a home for a Jakarta-wide catalog.
* It can be a home for...
This is what I have been trying for all along - I am sorry that I didn't
understand the implications of what is in the current proposal earlier -
I thought we were on an evolutionary path to it :)
> And I agree that the basics must be clear - and the essential one is that
> nobody should try to impose his "right way" on others - "there are more
> ways to do something".
Yep.
> > Because, (in my head), as Agora would be organizationally a peer to all
> > other 'productized compoenents', all Agora must do is stick to it's
> > charter (open incubator) and it is free to do that in any way the
> > committers of the Agora project see fit. Since it seems that the plan
> > is that every Jakarta committer would be an Agora committer, anything
> > could, would and should happen.
>
> To make it clear - since I noticed people start miss-interpreting Agora.
>
> The goal of Agora ( that I have in mind ) is not to be a place where
> anyone can do anything. The goal is to be a "safe place" where
> "more ways to do something" is the default and where projects may share
> code without the current tensions and develop it in common.
>
> In order to achieve that ( tension-free ) goal I am proposing that
> "ownership" of the agora is shared among all projects, and each component
> in agora can be started by any project ( without any restriction - if the
> code was good for the project and acceptred by it's commiters, it's ok for
> agora ). I.e. - no bariers for entry, they don't have to justify why their
> way to do it is valid, even if other projects believe it should be done
> otherwise or it's duplicated.
>
> ( but this rule is not proposed for "anyone can do anything" - that may be
> a by-product, and I don't think it is bad, but it's not the goal of agora)
>
> And the other rule ( that for each component, control is shared among
> projects using it ) is intended to solve tensions like the ones between
> tomcat and catalina ( i.e. a group/project feeling "ownership" of a
> component that is supposed to be shared ) - this rule should make it
> possible that after multiple components doing the same thing are present,
> project can merge them and choose among them, again without the feeling
> of "that's mine and this is yours" - you use it, it's yours too, you can't
> claim "your component brakes my code" anymore.
>
> So to make it clear - the agora ( component of commons ) is inteded to
> promote exchanges between projects, with the secondary goal of creating
> great code by sharing resources and ideas on a greater scale.
>
> It's not that agora will have some "random" code - almost all code in
> agora will be part of at least one project, i.e. used in real-world
> production systems.
That's fine. "I don't care." :) It's not that I really don't care (I
think its a great thing, and I hope to participate), but I want to do
the DBCP, and if we are successful decoupling the 'rooms' of the
library, I can do my thing, you can do yours, he can do his, she can do
hers, etc. Agora is a valuable thing. I think that productized
components would be a valuable thing. Both can live together in
parallel.
> For example, if Craig agrees to try again to share XmlMapper, that
> component is used and tested as part of quite a few betas and releases of
> tomcat and catalina. If we get to share "gtest" - you have something used
> in at least 3 projects, part of tomcat, watchdog and catalina.
>
> Another step might be to productize some of them ( as standalon )- but
> can't commit for this ( I know my time resources, and I'm not that
> interested )
>
> Costin
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
