David Weinrich wrote:
>
> As far as I understand it, this project is very similar to the 'commons'
> on a university campus ( sometimes called the quad or whatever else sounds
> good ). It is a place where the members of the university share common
> services like a library, usually a bookstore, etc... that don't fit into
> the purpose of the colleges/departments that make up the university. In
> the same way this project is more service-based than product-based.
I disagree with the analogy because I think something important is
getting left out. The productized-component-initiative is in this model
another department - the DBConnectionPool is just as valuable a
standalone project to software developers as ORO and Regexp is. It
would be a project in it's own right, with committers, docs, users, etc.
Now, I recognize that having these small components as independant
entitites in Jakarat as peers to Tomcat, Struts, etc, wouldn't scale
well, hence the notion of library or catalog - a place where these could
be [independantly!] productized.
>[SNIP]
> Jakarta Commons ( hey let's throw yet another name on the pile ;) Project
>
> Agora Service:
>
> * As described before a 'sandbox' where people from different
> projects can come together and work on taking common code
> and forming it into something that can be shared.
+1 : but it too is a project, I think, with open access to all Jakarta
committers, etc
> Catalog Service ( I've been tempted to propose calling this 'Dewey'
> after the old card catalog/subject numbering system
> subjected on many of us in earlier years ):
>
> * A way for end users to look up the products present in the library
> and in the jakarta projects. ( Ted can give a more detailed
> description of this :)
+1 -> this is what I was talking about in the first msg of this thread
as a 'Directory' not a catalog, as I thought of the catalog as a place
for 'ready for sale' components (I think you call it Library Service
below), but I agree with the idea, and so sick of tracking all the
names, it doesn't matter to me what it is called.
> Library Service:
>
> * A place for matured 'products' ( quite possibly developed in the
> Agora service ) to be stored for use/reuse by end users. Much of
> what makes up the library service provides is based upon the
> other two services, what really makes the difference is the
> standards set for inclusion of the products in the library as
> seperate products ( documentation, testing, support ).
+1 -> I hate the name :) But the important thing, I think, is that the
Library Service is just a shell - each product within is it's own
project like any other jakarta project. It is responsible for it's docs
separately from the other products, etc ,etc ,etc. Now, forcing
documentation and other standards would be great, but the idea of them
being little projects in their own right is important [to me].
> The goal shared by this project and the services it holds is the to
> facilitate sharing code that is common both internally within jakarta and
> the projects it holds and externally in the end products built with the
> products of jakarta by users.
No. I like the sentiment, but seems too complicated. If you just said
that 'Commons' mission is a Jakarta project to be a container / home for
small/misc projects that support the Jakarta mission, I think it would
work out the same way. Then Agora is a project, Catalog is a project,
and I think you can eliminate the library service idea, since each
entity in the Library service is a completely self-supporting project in
it's own right, so it might as well be a peer to Agora and Catalog, just
to keep people from having to dig too far to find things. In a diagram
:
Jakarta
|
| -> Tomtcat
| -> Commons
| |
| |->Agora
| |->Catalog
| |-> DBConnectionPool
| |-> XMLCOnfig
|
| -> Turbine
etc
> A side effect of this goal/project
> combination is it gives the jakarta committers a place to do this type of
> work and experimentation without having a detrimental effect to the
> projects they are working on. Hope this helps, and if I'm way off base
> anyone can fix up this description how they see fit.
This is true in two ways :
1) Agora gives them a place to muck around
2) Catalog provideds visibility for useful packages and components w/o
the added work of removing from a project codebase and supporting
outside of the project as well as removing any documentation requirement
that might come about when code is pushed out of a project.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
