Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > 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.
>
> I'm not sure what you're saying here, but let's just keep the sandbox as
> an adjunct to the Commons. If it really works that well, someone can
> always propose that it be convert to its own "Agora" subproject.
Let me try to be clear, as I think this is important :
If you simply make library a container for mini projects, charter Agora
from the start as a mini-project, then you get what everyone wants w/o
the journey of discovery of new and untested project management models.
> "Geir Magnusson Jr." wrote:
> > Further, I was trying to clarify how that could be encoded into the
> > charter of this project - each subproject in the library is an
> > independant project a la Jakarta, with a separate set of committers, so
> > there can be no cross project influenece or interferance.
>
> If you go there, then we should just start proposing packages as Jakarta
> subprojects.
I am a little suprised, as the phrase 'go there' implies that it is
going somewhere else/new.
Isn't that one of the basic principles of this whole thing, letting
small components be managed as standalone project entities under the
umbrella of a Jakarta library project? Isn't that why getting the
committer model right has been such an issue? It certainly has been what
I have been trying to say now for weeks.
I thought that because having every little component as a subproject of
Jakarta wouldn't scale and when you have multiple of them would require
organization, that this is what we were doing - making a place where
productized components, 'mini-Jakarta-projects' can live.
This is what I was trying to do privately for a DBCP before the library
discussion started, it is what I wanted to ensure happened in library
(and am happy to see other things like Agora and Catalog/Directory
happen too...), and it is what I will continue to try to do if people
here don't think that is appropriate for library.
(PoolMan is a great example of what I think of as a DBCP project for
'library'. XML-RPC client and server API implementations is another
thing that should be available from Jakarta... In each case, if you
were going to use it as fundamental building blocks in a production
system, you won't be wanting to be sucking them out of someones nightly
snapshot tarball. You want a versioned, standalone jar of each. I
would, anyway.)
Fundamentally : I think we need a mechanism for productizing into useful
components for Java server developers the rich and varied code present
in the Jakarta codebases.
I already can do this - I just can take the best ideas and code from
whatever is in Jakarta or write new stuff, try to get a few people from
the various projects who have experience and are interested to
participate, work together to make a concrete implementation, document
it, and then propose to the PMC a new project.
But since I felt that a DBCP would be too small to include in Jakarta as
a separate entity, and that the PMC wouldn't be interested in more small
tool-ish components , then I thought a 'library' or 'catalog' project,
something to hold the mini-projects was a good idea, and that is why I
participate in this.
Sorry if I have been wasting anyones time with these discussions, but I
think I have been clear from the start. It is why I wrote the 'Plea for
Clarification' post, trying to step back and clarify this issue, and
futher the 'Riffing ...' post should have given hint that I was
apparently off in the weeds - proposing as a separate project some of
Teds catalog ideas.
Confused in Connecticut,
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
