You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by David Weinrich <dw...@home.com> on 2001/03/01 00:25:27 UTC
Re: Riffing again on another tangent
On Wed, 28 Feb 2001, Sam Ruby wrote:
> Geir Magnusson Jr. wrote:
> >
> > So in a sense, Directory is another library project with open
> > rules (like agora). (Not sure if Agora was going to be a
> > Library peer in Jakarta-land, or a 'product peer' in Library-land.
>
> My biggest concern is that I don't understand the relationship between
> Library, Directory, Agora, and Avalon.
>
> Avalon has been in the process of splitting into multiple cvs repositories,
> using the naming convention of jakarta-avalon-xxx.
>
> It would be a simple matter to create a jakarta-avalon-dbpool.
>
> I'd like to hear consensus with someone representing jakarta-avalon (i.e.,
> Peter Donald) before creating another subproject with overlapping goals.
>
> - Sam Ruby
>
>
Sorry for not including the text of the responses to this, I'll answer
those seperately later. I think I have a way of describing the project
that would make the distinction clearer. I sent an email describing the
differences between this project and avalon earlier and a few others have
stated similar descriptions so I'll concentrate on one thing: describing
this project.
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. In the
same way this project is very much focused on being neutral in terms of
'belonging' to one project or another ( note that I will not claim that
politics won't happen here, in many cases political discussions occur
mainly in the common/shared area of an organization by nature, and
shouldn't be seen as a 'bad' thing or counterproductive ). So here is a
quick map of how I see the project:
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.
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 :)
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 ).
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. 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.
David
Re: Riffing again on another tangent
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> 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
Heretofore, Jakarta subprojects have used CVS, mailing-list, and
Bugzilla services to create and maintain codebases.
Agora really wouldn't be a "subproject", since it is really just a
maverick CVS repository for Jakarta committers (a little like a
teacher's lounge).
I expect that the codebase for the catalog would be maintained in the
Library CVS repository, but the Commons would also be offering a working
INSTANCE of the catalog.
So, both of these really look like services, running along side the
actual library CVS repository.
Jakarta
|
| -> Jakarta-site2
| |Mailing Lists
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |...
| |Bugzilla
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |...
| -> Commons
| |Agora CVS
| |Catalog instance
| |Library CVS
| |-> Catalog (codebase)
| |-> DBConnectionPool
| |-> XMLConfig
| |...
| -> Tomcat CVS
| |-> Catalina
| |-> Jasper
|
| -> Turbine
etc
Though, it might be cleaner if the Catalog instance and Agora CVS were
an expansion of the core Jakarta-site, and acted as services alongside
the
Mailing Lists and Bugzilla, so there would be
Jakarta
|
| -> Jakarta-site
| |Mailing Lists
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |-> ...
| |Bugzilla
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |-> ...
| |Catalog instance
| |-> ...
| |Agora CVS
| |-> ...
| |Gump instance
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |Site2 CVS
| |-> Web site
| -> Library CVS
| |-> Catalog (codebase)
| |-> DBConnectionPool
| |-> XMLConfig
| |-> Gump (codebase)
| |-> Web site
| |...
| -> Tomcat CVS
| |-> Catalina
| |-> Jasper
| |-> Web site
| -> Turbine CVS
etc
It's just that, IMHO, a Sandbox or Agora CVS and a catalog are both
essential to the longterm success of a Library subproject, and so
there's been a tendancy to group them together.
-Ted.
Re: Riffing again on another tangent
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> 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
Heretofore, Jakarta subprojects have used CVS, mailing-list, and
Bugzilla services to create and maintain codebases.
Agora really wouldn't be a "subproject", since it is really just a
maverick CVS repository for Jakarta committers (a little like a
teacher's lounge).
I expect that the codebase for the catalog would be maintained in the
Library CVS repository, but the Commons would also be offering a working
INSTANCE of the catalog.
So, both of these really look like services, running along side the
actual library CVS repository.
Jakarta
|
| -> Jakarta-site2
| |Mailing Lists
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |...
| |Bugzilla
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |...
| -> Commons
| |Agora CVS
| |Catalog instance
| |Library CVS
| |-> Catalog (codebase)
| |-> DBConnectionPool
| |-> XMLConfig
| |...
| -> Tomcat CVS
| |-> Catalina
| |-> Jasper
|
| -> Turbine
etc
Though, it might be cleaner if the Catalog instance and Agora CVS were
an expansion of the core Jakarta-site, and acted as services alongside
the
Mailing Lists and Bugzilla, so there would be
Jakarta
|
| -> Jakarta-site
| |Mailing Lists
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |-> ...
| |Bugzilla
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |-> ...
| |Catalog instance
| |-> ...
| |Agora CVS
| |-> ...
| |Gump instance
| |-> Tomcat
| |-> Commons
| |-> Turbine
| |Site2 CVS
| |-> Web site
| -> Library CVS
| |-> Catalog (codebase)
| |-> DBConnectionPool
| |-> XMLConfig
| |-> Gump (codebase)
| |-> Web site
| |...
| -> Tomcat CVS
| |-> Catalina
| |-> Jasper
| |-> Web site
| -> Turbine CVS
etc
It's just that, IMHO, a Sandbox or Agora CVS and a catalog are both
essential to the longterm success of a Library subproject, and so
there's been a tendancy to group them together.
-Ted.
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 01:40 1/3/01 -0500, Geir Magnusson Jr. wrote:
> >One way to solve this since the Commons idea is a good one, and
> >different in deliverables than 'regular' jakarta projects, we could look
> >at changing whatever Avalon's charter really is to include the
> >productized component project there (Library).
> >
> >Of course, this would be a decision by the Avalon folk to change their
> >model of dealing with components. I only bring this up because I get the
> >sense that the Avalon folk are interested.
>
> I think there is interest in it. It is something I have wanted to do since
> Jon mentioned the CJAN idea - it has also been mentioned with regards to
> another Enterprise Application super-server built on top of Phoenix. So if
> the infrastructure was there people would definetly be willing to do it I
> suspect.
Just to be clear, what I am suggesting is Avalon being a home for
component projects that are managed by their own set of committers -
each is an independant project with their own deliverables,
documentation, examples, jars. I assume that the individuals that
comprise the Avalon committers would be a part of each out of their
interest this stuff, but it wouldn't be the default or required.
This doesn't mean I am advocating changing what[ever] Avalon is now -
but rather just bolting an 'addition' onto the side, so to speak.
I think that is a little different than CJAN.
Or I am too tired to think now. Have a good evening, everyone. :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 01:40 1/3/01 -0500, Geir Magnusson Jr. wrote:
> >One way to solve this since the Commons idea is a good one, and
> >different in deliverables than 'regular' jakarta projects, we could look
> >at changing whatever Avalon's charter really is to include the
> >productized component project there (Library).
> >
> >Of course, this would be a decision by the Avalon folk to change their
> >model of dealing with components. I only bring this up because I get the
> >sense that the Avalon folk are interested.
>
> I think there is interest in it. It is something I have wanted to do since
> Jon mentioned the CJAN idea - it has also been mentioned with regards to
> another Enterprise Application super-server built on top of Phoenix. So if
> the infrastructure was there people would definetly be willing to do it I
> suspect.
Just to be clear, what I am suggesting is Avalon being a home for
component projects that are managed by their own set of committers -
each is an independant project with their own deliverables,
documentation, examples, jars. I assume that the individuals that
comprise the Avalon committers would be a part of each out of their
interest this stuff, but it wouldn't be the default or required.
This doesn't mean I am advocating changing what[ever] Avalon is now -
but rather just bolting an 'addition' onto the side, so to speak.
I think that is a little different than CJAN.
Or I am too tired to think now. Have a good evening, everyone. :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 01:40 1/3/01 -0500, Geir Magnusson Jr. wrote:
>One way to solve this since the Commons idea is a good one, and
>different in deliverables than 'regular' jakarta projects, we could look
>at changing whatever Avalon's charter really is to include the
>productized component project there (Library).
>
>Of course, this would be a decision by the Avalon folk to change their
>model of dealing with components. I only bring this up because I get the
>sense that the Avalon folk are interested.
I think there is interest in it. It is something I have wanted to do since
Jon mentioned the CJAN idea - it has also been mentioned with regards to
another Enterprise Application super-server built on top of Phoenix. So if
the infrastructure was there people would definetly be willing to do it I
suspect.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by Peter Donald <do...@apache.org>.
At 01:40 1/3/01 -0500, Geir Magnusson Jr. wrote:
>One way to solve this since the Commons idea is a good one, and
>different in deliverables than 'regular' jakarta projects, we could look
>at changing whatever Avalon's charter really is to include the
>productized component project there (Library).
>
>Of course, this would be a decision by the Avalon folk to change their
>model of dealing with components. I only bring this up because I get the
>sense that the Avalon folk are interested.
I think there is interest in it. It is something I have wanted to do since
Jon mentioned the CJAN idea - it has also been mentioned with regards to
another Enterprise Application super-server built on top of Phoenix. So if
the infrastructure was there people would definetly be willing to do it I
suspect.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
One way to solve this since the Commons idea is a good one, and
different in deliverables than 'regular' jakarta projects, we could look
at changing whatever Avalon's charter really is to include the
productized component project there (Library).
Of course, this would be a decision by the Avalon folk to change their
model of dealing with components. I only bring this up because I get the
sense that the Avalon folk are interested.
David Weinrich wrote:
> 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.
> |
| -> Avalon
| |
| |-> server framework thingy
| |
> | |->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
>
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Weinrich wrote:
> > 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.
And the spelling was spectacular too.
:)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Weinrich wrote:
> > 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.
And the spelling was spectacular too.
:)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
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. geirm@optonline.com
> Developing for the web? See http://jakarta.apache.org/velocity/
>
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
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. geirm@optonline.com
> Developing for the web? See http://jakarta.apache.org/velocity/
>
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
One way to solve this since the Commons idea is a good one, and
different in deliverables than 'regular' jakarta projects, we could look
at changing whatever Avalon's charter really is to include the
productized component project there (Library).
Of course, this would be a decision by the Avalon folk to change their
model of dealing with components. I only bring this up because I get the
sense that the Avalon folk are interested.
David Weinrich wrote:
> 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.
> |
| -> Avalon
| |
| |-> server framework thingy
| |
> | |->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
>
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
On Thu, 1 Mar 2001, Geir Magnusson Jr. wrote:
> 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.
I agree, the names do get confusing after a while ;) See below for more...
>
> > 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).
> > 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 :).
> 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. The catalog is
mostly a reference to what is where ( I hope, Ted is this close? ). 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 ). 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.
>
> 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.
>
> > 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. geirm@optonline.com
> Developing for the web? See http://jakarta.apache.org/velocity/
>
Re: Riffing again on another tangent
Posted by David Weinrich <dw...@home.com>.
On Thu, 1 Mar 2001, Geir Magnusson Jr. wrote:
> 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.
I agree, the names do get confusing after a while ;) See below for more...
>
> > 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).
> > 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 :).
> 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. The catalog is
mostly a reference to what is where ( I hope, Ted is this close? ). 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 ). 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.
>
> 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.
>
> > 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. geirm@optonline.com
> Developing for the web? See http://jakarta.apache.org/velocity/
>
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Riffing again on another tangent
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/