I've cut out some of the earlier stuff to keep this from getting too
deeply nested.
On Thu, 1 Mar 2001, Geir Magnusson Jr. wrote:
> >
> > 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.
>
Agreed
> > > > 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.
>
Ok, I can see how the word 'Service' doesn't help clarify, and I agree
with the 'jakarta on a smaller scale' idea.
>
> > > 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.'
Excellent wording.
>
> > 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.'
>
Again, right on the point.
> > 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.
>
Agreed
> >
> > >
> > > 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.
>
The big point I see is there is a natural connection between the three
things that we have been talking about today. Keeping them in one place
will hopefully help keep us from building more walls.
> geir
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> Developing for the web? See http://jakarta.apache.org/velocity/
>
