David Weinrich wrote:
> > > 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].
> >
>
> Right, each product in the library will have it's own set of
> documentation/webpages/maintainers and will exist in the library. I see a
> contrast between this and the 'Directory/Catalog' as the difference
> between a set of books, and the searchable description/card catalog that
> people use to find the right book(s).
Clearly - and it would be great if all Jakarta committers had default
write access to this - let everyone list the things they [think] they
have.
> > > 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.
>
> If you insert the word services somewhere, I think that is pretty damn
> close. Hell that sentence even confused me when I read it again, sorry for
> the wording and structure :).
Well - my point is that the notion of service is superfluous. To me,
saying it's 'for services' to the jakarta community, and then making
Library a service that holds projects just adds a layer I don't see as
necessary. Further, it limits what you can include if what can be
included has to be a 'service'.
The notion of project-as-service already has a precedent in Jakarta :
Taglibs.
What I am trying to say, not too clearly I suppose, is that they should
just be projects. If the project happens to be a 'service' in the sense
of Agora and Catalog, great. There is precedence for that in Taglibs.
If it is a normal Jakarta project like 'Ye Olde DB Connection Pool',
great too. I think you have more flexibility, and the organizational
model is understandable, as it's just Jakarta on a smaller length scale.
> > 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
> > :
>
> if you say it as 'Agora is a service, Catalog is a service, and Library is
> a place to put the actual components' it makes more sense.
Not to me, since the project-as-service idea works pretty well already
in Taglibs, right?
> The catalog is
> mostly a reference to what is where ( I hope, Ted is this close? ).
Right. A directory :)
Or, 'The catalog is a project whose deliverable is a reference to what
is where, and a way for committers in the Jakarta projects to make
entried in that directory.'
> Agora
> is a common area for different projects to come together and find a way to
> turn the code inside their projects into a common tool ( or even propose a
> new tool if no implementation exists ).
Or 'Agora is a project whose charter is to provide CVS and other
resources to support the sharing of code across jakarta codebases, as
well as act as an incubator, a workplace for new ideas.'
> The library is where the tools get
> put, once they have reached a point where the API and the code is stable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and the documentation/support structure for that component is worked out
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and meets some kind of standards.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
First, requiring that it 'reach the point' is something not currently
required of Jakarta projects.
Second, ignoring the requirement of completeness, how is that different
than a regular jakarta project?
Giving me a little slack with the following analogy, if Oro and Taglibs
are both projects and both peers in the Jakarta universe, then
'DBConnectionPool' and 'Agora' are both projects and peers.
My point is that making service a new 'first-class citizen' in
Jakartaland doesn't add anything, since you could accomplish all you
wish for by just keeping them projects.
>
> >
> > Jakarta
> > |
> > | -> Tomtcat
> > | -> Commons
> > | |
> > | |->Agora
> > | |->Catalog
> > | |-> DBConnectionPool
> > | |-> XMLCOnfig
> > |
> > | -> Turbine
> > etc
>
> Ok I'll take a stab at this too :)
>
> Jakarta
> |
> | -> Tomtcat
> | -> Commons
> | |
> | |->Agora
> | | |-> A collection of projects in the process of creating
> | | components, with people collaborating from different
> | | jakarta projects.
> | |
> | |->Catalog
> | | |-> Searchable links to what is available where.
> | |
> | |->Library
> | | |
> | | |-> DBConnectionPool
> | | |-> XMLCOnfig
> | | |-> A set of reusable components that have reached a stable
> | point in their lifecycle and meet standards for support
> | infrastructure and documentation.
> |
> | -> Turbine
>
> Hopefully this is a bit more clear compared to my somewhat confuzzled
> writing.
It was clear at first. No worries. I just don't see the point of
putting them down yet another layer.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
