Re: Riffing again on another tangent

[Sam Ruby <ru...@us.ibm.com>]

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

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Peter Donald wrote:
> 
> At 12:29  28/2/01 -0800, Morgan Delagrange wrote:
> >Note that Avalon is a _framework_ for servers, which
> 
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?"). 

To wit:  

< http://www.mail-archive.com/general@jakarta.apache.org/msg00022.html >

Avalon is;
1. A repository of general utility code (CLI parsing, cascading
exceptions,
StringUtils, etc)
2. A repository of patterns and framework code (ie component lifecycle
code
and mamanagement code - think logging, configuring Startable, Stoppable
Suspendable, Reesumable)
3. A set of general utility code based on (2) that offers "doing" code
and
extended patterns. (ie object pooling, thread management, classloader
management, policy management, utility classes that "run" components
lifecycle, Container-Component patterns and implementations,
Kernel-Application-Component patterns and implementation).
4. A micro kernel for running services
5. A set of services that are orientated towards server environments (ie
SocketFactories, ConnectionManagers, Schedulers etc)

After hearing this they look at it and goes - is good but is alpha -
call
me when it's beta ;) It is then I explain that (2) can be considered
largely stable and fixed, (1) and (3) usually are added to and would be
considered beta-stable. The only components that are alpha would be part
of
(3), (4) and (5). 

And even within in that there are distinctions. ie The client interface
to
the kernel in (4) is stable but the actuall kernel implementation is
not.
(Consider this the same as difference between servlet and servlet
engines).

So recently we voted and decided that we want to release the different
components on different schedules. We have three basic components

avalon (1)->(3) (Thou eventually (1) should move to it's own project ala
AUT)
phoenix (4)
cornerstone (5)

That can stand on their own and have varying release schedules and
degrees
of stability. Initially you may look at it and say that cornerstone is
not
separate enough from phoenix to be worthy of a different release
schedule
and there is not enough content in it. I initially tended to agree but
there is indications that soon (post valentines day) there will be a
surge
in the number of core services offered and there will be enough for it
to
have a separate release schedule.

At this point it may seem like it would be a good idea to ask the PMC to
split the project into multiple sub-projects. However I would tend to
disagree. The same people are developers for all three sections and it
would be dividing too many resources. Maybe in the future it may be
advisable to do this but it is not the future yet ;)

So we would like to split the CVS into three separate
subprojects/subCVSes
(jakarta-cornerstone, jakarta-avalon and jakarta-phoenix). This would
allow
us to safely have different release schedules and would give a sense of
stability to those who just want to use the jakarta-avalon component. It
would also force us to stabilize faster as we wouldn't be able to as
easily
intermingle changes ;)

So in summary what we would like to do is have three deliverables within
the same project. Namely;

jakarta-avalon (Beta->STABLE)
jakarta-phoenix (Alpha->Beta)
jakarta-cornerstone (Alpha)

Thoughts?
Cheers,

Pete

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Peter Donald wrote:
> 
> At 12:29  28/2/01 -0800, Morgan Delagrange wrote:
> >Note that Avalon is a _framework_ for servers, which
> 
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?"). 

To wit:  

< http://www.mail-archive.com/general@jakarta.apache.org/msg00022.html >

Avalon is;
1. A repository of general utility code (CLI parsing, cascading
exceptions,
StringUtils, etc)
2. A repository of patterns and framework code (ie component lifecycle
code
and mamanagement code - think logging, configuring Startable, Stoppable
Suspendable, Reesumable)
3. A set of general utility code based on (2) that offers "doing" code
and
extended patterns. (ie object pooling, thread management, classloader
management, policy management, utility classes that "run" components
lifecycle, Container-Component patterns and implementations,
Kernel-Application-Component patterns and implementation).
4. A micro kernel for running services
5. A set of services that are orientated towards server environments (ie
SocketFactories, ConnectionManagers, Schedulers etc)

After hearing this they look at it and goes - is good but is alpha -
call
me when it's beta ;) It is then I explain that (2) can be considered
largely stable and fixed, (1) and (3) usually are added to and would be
considered beta-stable. The only components that are alpha would be part
of
(3), (4) and (5). 

And even within in that there are distinctions. ie The client interface
to
the kernel in (4) is stable but the actuall kernel implementation is
not.
(Consider this the same as difference between servlet and servlet
engines).

So recently we voted and decided that we want to release the different
components on different schedules. We have three basic components

avalon (1)->(3) (Thou eventually (1) should move to it's own project ala
AUT)
phoenix (4)
cornerstone (5)

That can stand on their own and have varying release schedules and
degrees
of stability. Initially you may look at it and say that cornerstone is
not
separate enough from phoenix to be worthy of a different release
schedule
and there is not enough content in it. I initially tended to agree but
there is indications that soon (post valentines day) there will be a
surge
in the number of core services offered and there will be enough for it
to
have a separate release schedule.

At this point it may seem like it would be a good idea to ask the PMC to
split the project into multiple sub-projects. However I would tend to
disagree. The same people are developers for all three sections and it
would be dividing too many resources. Maybe in the future it may be
advisable to do this but it is not the future yet ;)

So we would like to split the CVS into three separate
subprojects/subCVSes
(jakarta-cornerstone, jakarta-avalon and jakarta-phoenix). This would
allow
us to safely have different release schedules and would give a sense of
stability to those who just want to use the jakarta-avalon component. It
would also force us to stabilize faster as we wouldn't be able to as
easily
intermingle changes ;)

So in summary what we would like to do is have three deliverables within
the same project. Namely;

jakarta-avalon (Beta->STABLE)
jakarta-phoenix (Alpha->Beta)
jakarta-cornerstone (Alpha)

Thoughts?
Cheers,

Pete

Re: Riffing again on another tangent

[Peter Donald <do...@apache.org>]

At 12:29  28/2/01 -0800, Morgan Delagrange wrote:
>Note that Avalon is a _framework_ for servers, which

Not necessarily ;) Avalon is a name with many faces. We are trying to
separate out each of these at the moment but we are still no there. I
posted a list of 5 things I though Avalon was on general@jakarta (under
subject "What is Avalon?"). I was also mailed off list with two other
things that Avalon could be interpreted as being - so I guess when you say
"Avalon" you have to qualify it which particular component ;)


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

["Geir Magnusson Jr." <ge...@optonline.net>]

Ted Husted wrote:
> 
> Sam Ruby wrote:
> > My biggest concern is that I don't understand the relationship between
> > Library, Directory, Agora, and Avalon.
> 
> I'm still not clear on Avalon's current mission, so I can't comment on
> that.
> 
> Agora is a label that Costin proposed. At this point, it's shifted
> toward a name for the Library subproject (along with other candidates
> like Rupert and Zarf).

I thought 'Agora' was the name that Costin proposed for the
repository/incubator idea. Which I thought was an *excellent* name for
that.

I like simple names that convey meaning when naming projects, and Agora
nails it right on the head.

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Riffing again on another tangent

["Geir Magnusson Jr." <ge...@optonline.net>]

Ted Husted wrote:
> 
> Sam Ruby wrote:
> > My biggest concern is that I don't understand the relationship between
> > Library, Directory, Agora, and Avalon.
> 
> I'm still not clear on Avalon's current mission, so I can't comment on
> that.
> 
> Agora is a label that Costin proposed. At this point, it's shifted
> toward a name for the Library subproject (along with other candidates
> like Rupert and Zarf).

I thought 'Agora' was the name that Costin proposed for the
repository/incubator idea. Which I thought was an *excellent* name for
that.

I like simple names that convey meaning when naming projects, and Agora
nails it right on the head.

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Sam Ruby wrote:
> My biggest concern is that I don't understand the relationship between
> Library, Directory, Agora, and Avalon.

I'm still not clear on Avalon's current mission, so I can't comment on
that. 

Agora is a label that Costin proposed. At this point, it's shifted
toward a name for the Library subproject (along with other candidates
like Rupert and Zarf). 

Discussions aside, at this point in time, there is only one subproject
proposal on the table. It is described at 

< http://husted.com/about/jakarta/lib005.html >

The subproject would host a catalog, or directory if you will. This
index will list the packages created and maintained by the Library
subproject. It will also list other packages offered elsewhere in
Jakarta-land (i.e, available at other "branches"). I'm thinking of it as
a precursor to CJAN.

Costin and Ignacio have said many times that they wish there were an
independent repository where committers could work on code to be shared
between subprojects, or as a sandbox or incubator. Originally, he
proposed using Jakarta-Util for this, but the vote tanked. On Monday,
Costin started calling this Agora, but when we came to the idea of
adding a sandbox to the library subproject, he signed up for that. And
so, Agora became a candidate name for the library. 

The library sandbox CVS would be open to any Jakarta committer, no vote
required or questions asked. However, to release a package, they would
have to propose it to the Library or another subproject, so that the
codebase is subjected to peer review and a release vote.

-T.

Re: Riffing again on another tangent

[Peter Donald <do...@apache.org>]

At 12:29  28/2/01 -0800, Morgan Delagrange wrote:
>Note that Avalon is a _framework_ for servers, which

Not necessarily ;) Avalon is a name with many faces. We are trying to
separate out each of these at the moment but we are still no there. I
posted a list of 5 things I though Avalon was on general@jakarta (under
subject "What is Avalon?"). I was also mailed off list with two other
things that Avalon could be interpreted as being - so I guess when you say
"Avalon" you have to qualify it which particular component ;)


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

["Geir Magnusson Jr." <ge...@optonline.net>]

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.

With the big exception of the productized components, Avalon is
completely separate from Lib, Dir, Ag.  But you are right, one of the
[many :)] interpretations of Avalon could be that of hosting productized
components.

I just thought that having a directory of 'stuff' so people (internal to
Jakarta as well as, and maybe more importantly outsiders) can find
things is important - the recognition of the richness of the Jakarta
codebases is what got me started on this in the first place..
 
> 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 am all for jakarta-avalon-dbpool as long as its separable from Avalon
in build, documentation and independence of purpose. By this I mean that
the dbpool can primarily implement standard JDBC-compliant interfaces
and conventions, and is not required to fit into the Avalon-patterns or
framework.

I think it would be great to house it there - if avalon turns out to be
what I want library to be, you'll see me there :)

> I'd like to hear consensus with someone representing jakarta-avalon (i.e.,
> Peter Donald) before creating another subproject with overlapping goals.
> 
> - Sam Ruby

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Sam Ruby wrote:
> My biggest concern is that I don't understand the relationship between
> Library, Directory, Agora, and Avalon.

I'm still not clear on Avalon's current mission, so I can't comment on
that. 

Agora is a label that Costin proposed. At this point, it's shifted
toward a name for the Library subproject (along with other candidates
like Rupert and Zarf). 

Discussions aside, at this point in time, there is only one subproject
proposal on the table. It is described at 

< http://husted.com/about/jakarta/lib005.html >

The subproject would host a catalog, or directory if you will. This
index will list the packages created and maintained by the Library
subproject. It will also list other packages offered elsewhere in
Jakarta-land (i.e, available at other "branches"). I'm thinking of it as
a precursor to CJAN.

Costin and Ignacio have said many times that they wish there were an
independent repository where committers could work on code to be shared
between subprojects, or as a sandbox or incubator. Originally, he
proposed using Jakarta-Util for this, but the vote tanked. On Monday,
Costin started calling this Agora, but when we came to the idea of
adding a sandbox to the library subproject, he signed up for that. And
so, Agora became a candidate name for the library. 

The library sandbox CVS would be open to any Jakarta committer, no vote
required or questions asked. However, to release a package, they would
have to propose it to the Library or another subproject, so that the
codebase is subjected to peer review and a release vote.

-T.

Re: Riffing again on another tangent

[Peter Donald <do...@apache.org>]

At 10:27  1/3/01 -0800, cmanolache@yahoo.com wrote:
>Well, sorry about the previous mail, it didn't sounded as I wanted.

;)

>All I'm trying to say is that the Library is significantly bigger than
>Avalon - in both scope and intended community.

I think you are mixing content and form. 

The form being the infrastructure (gump/cjan etc). The form is
fundamentally larger than any other aspect in this project and IMHO it
should be a separate entity in itself integrated into ant/alexandria/gump.
I would propose this but I am not willing to do the work ;) 

I believe Jon even created either a directory or CVS or something for CJAN
but as yet only one other person (Conor from ant-dev) has expressed
interesting in actually doing the work ;) The details of which are buried
somewhere in ant-dev archives - though I could search through them if you
want ;)

The content between proposed library content and Avalon overlaps however
which I would want to avoid. 

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

[Peter Donald <do...@apache.org>]

At 10:27  1/3/01 -0800, cmanolache@yahoo.com wrote:
>Well, sorry about the previous mail, it didn't sounded as I wanted.

;)

>All I'm trying to say is that the Library is significantly bigger than
>Avalon - in both scope and intended community.

I think you are mixing content and form. 

The form being the infrastructure (gump/cjan etc). The form is
fundamentally larger than any other aspect in this project and IMHO it
should be a separate entity in itself integrated into ant/alexandria/gump.
I would propose this but I am not willing to do the work ;) 

I believe Jon even created either a directory or CVS or something for CJAN
but as yet only one other person (Conor from ant-dev) has expressed
interesting in actually doing the work ;) The details of which are buried
somewhere in ant-dev archives - though I could search through them if you
want ;)

The content between proposed library content and Avalon overlaps however
which I would want to avoid. 

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

[David Weinrich <dw...@home.com>]

On Thu, 1 Mar 2001, Peter Donald wrote:


>
> When you say Avalon - what are you referring to exactly? If you are
> referring to the frameowork components or cornerstone components then I
> agree - if not then you are going to have to explain it further ;)
> Cheers,
>

I think this is the core issue that we are having problem resolving here.
Avalon is not clearly defined enough for us to make this judgement from
outside, and the sources of information ( the website vs. the emails
posted by yourself describing Avalon ) are sufficiently different to cause
even more confusion. I think we are very close to reaching a consensus on
what the Commons project and the Library/Agora/Catlog services within that
project consist of, and the goals of the project. And to be brief ( while
also beating the poor dead horse yet again ), Avalon has an existing
product for which it is known for, an existing set of developers who
developed that product with specific design goals and methods, and an
existing userbase that is using that product ( James is based upon Avalon
if I understand correctly ). Instead of trying to cram the
ideas/goals/objectives identified on this list into an existing project,
why don't we move forward and create a set of services and infrastructure
without destroying what Avalon has already done or is trying to do.

David

> 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

[David Weinrich <dw...@home.com>]

On Thu, 1 Mar 2001, Peter Donald wrote:


>
> When you say Avalon - what are you referring to exactly? If you are
> referring to the frameowork components or cornerstone components then I
> agree - if not then you are going to have to explain it further ;)
> Cheers,
>

I think this is the core issue that we are having problem resolving here.
Avalon is not clearly defined enough for us to make this judgement from
outside, and the sources of information ( the website vs. the emails
posted by yourself describing Avalon ) are sufficiently different to cause
even more confusion. I think we are very close to reaching a consensus on
what the Commons project and the Library/Agora/Catlog services within that
project consist of, and the goals of the project. And to be brief ( while
also beating the poor dead horse yet again ), Avalon has an existing
product for which it is known for, an existing set of developers who
developed that product with specific design goals and methods, and an
existing userbase that is using that product ( James is based upon Avalon
if I understand correctly ). Instead of trying to cram the
ideas/goals/objectives identified on this list into an existing project,
why don't we move forward and create a set of services and infrastructure
without destroying what Avalon has already done or is trying to do.

David

> 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

[Peter Donald <do...@apache.org>]

At 10:25  1/3/01 -0800, cmanolache@yahoo.com wrote:
>> But Avalon was intended to be a shared repository of server-side components
>> - it has no other purpose ;) All the other projects create server-side
>> components as a side effect of developing another product. Avalons product
>> is the components.
>
>Which is a very generic term - like saying the goal of a project is to
>create java code, or a server-side templating system. 

Or perhaps that the goal of this project is to create library of reusable
components for server side products - oh wait - thats the goal of this
project ! ;)

>And if you are saying that Avalon was supposed to do what we want for the
>libary - provide "catalog" and "common development" for projects - then it
>obviously failed ( since jakarta projects are still duplicating code
>instead of participating in avalon ) - so there is no point in discussing
>this :-)

Well yes a lot of people have said Avalon has failed so far ;) But that
doesn't say it still can not suceed ;)

>> I don't see how having two separate projects who do the same thing could be
>> good for jakarta. Could you imagine if someone proposed another servlet
>> engine at jakarta - Do you think that another servlet engine that served
>> roughly the same purpose would be good for Jakarta? (I don't think so)
>> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
>> engine ? (perhaps they get associated with Apache).
>
>Yes, that already happened and we survived. I would say ( IMHO !!) that
>the net effect was quite good (!).
>
>And Apache has 2 xml parsers, 

which serve different purposes

>multiple template engines, 

which serve different purposes

>multiple flavors of regexps. 

don't know what the difference is between them ;)

>Choice is good - each may be better suited for a different
>environment ( like tomcat 3.x is the only solution for JDK1.1 and
>catalina / 4.x for  people wanting servlet 2.3 support - to give only a
>"neutral" example )

3.3 vs catalina is the same project just different versions. Once catalina
graduates I assume 3.x will no longer be distributed at the same time and
catalina will adopt Tomcat name. 

It is actually this type of approach that I am advocating. Consider Avalon
as the 3.3 that currently exists and library as the 4.x version ;) I
welcome internal fork forks but parrallel development in jakarta on very
similar products is not something I want to see.

>> I agree - all code sits on its' own merits and these components should not
>> (at least in base form) be integrated into the rest of Avalon. The
>> cornerstone CVS may integrate components from the catalog/agora CVS into
>> the Avalon services/kernel API but I don't see this as something the
>> catalog/agora should do by itself. 
>
>I see it the other way around - avalon components should be treated equal
>with components developed by other projects, and "promoted" based on
>their actual use in projects and user adoption.

Isn't that what I just said ? ;)

>Merging this project with avalon would sugest that avalon components are
>"special" compared with components from other project. And that would be
>wrong.

I am not sure where you get this impression - I hope I haven't given you
that impression. Even within Avalon we have had competing implementaions of
things. At one stage we had 3 different pooling frameworks, 3 different
schedulers and different server-socket abstractions. Merit determins which
ones last and which are burned away.

>> By opening another CVS and giving everybody karma/voting rights/whatever
>> then I  believe the community would manage itself ;) If you think it is a
>> bad idea to integrate with the framework part of Avalon then don't ;) I
>> would even allow components integrated with other frameworks be added (with
>> the proviso that they would be refactored to use JavaBeans standard
overtime).
>
>Again - I think it's the other way around. 
>
>Avalon components could be integrated in the library, if they are not
>dependent on a framework - and avalon decides to. 

When you say Avalon - what are you referring to exactly? If you are
referring to the frameowork components or cornerstone components then I
agree - if not then you are going to have to explain it further ;)
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

[Peter Donald <do...@apache.org>]

At 10:25  1/3/01 -0800, cmanolache@yahoo.com wrote:
>> But Avalon was intended to be a shared repository of server-side components
>> - it has no other purpose ;) All the other projects create server-side
>> components as a side effect of developing another product. Avalons product
>> is the components.
>
>Which is a very generic term - like saying the goal of a project is to
>create java code, or a server-side templating system. 

Or perhaps that the goal of this project is to create library of reusable
components for server side products - oh wait - thats the goal of this
project ! ;)

>And if you are saying that Avalon was supposed to do what we want for the
>libary - provide "catalog" and "common development" for projects - then it
>obviously failed ( since jakarta projects are still duplicating code
>instead of participating in avalon ) - so there is no point in discussing
>this :-)

Well yes a lot of people have said Avalon has failed so far ;) But that
doesn't say it still can not suceed ;)

>> I don't see how having two separate projects who do the same thing could be
>> good for jakarta. Could you imagine if someone proposed another servlet
>> engine at jakarta - Do you think that another servlet engine that served
>> roughly the same purpose would be good for Jakarta? (I don't think so)
>> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
>> engine ? (perhaps they get associated with Apache).
>
>Yes, that already happened and we survived. I would say ( IMHO !!) that
>the net effect was quite good (!).
>
>And Apache has 2 xml parsers, 

which serve different purposes

>multiple template engines, 

which serve different purposes

>multiple flavors of regexps. 

don't know what the difference is between them ;)

>Choice is good - each may be better suited for a different
>environment ( like tomcat 3.x is the only solution for JDK1.1 and
>catalina / 4.x for  people wanting servlet 2.3 support - to give only a
>"neutral" example )

3.3 vs catalina is the same project just different versions. Once catalina
graduates I assume 3.x will no longer be distributed at the same time and
catalina will adopt Tomcat name. 

It is actually this type of approach that I am advocating. Consider Avalon
as the 3.3 that currently exists and library as the 4.x version ;) I
welcome internal fork forks but parrallel development in jakarta on very
similar products is not something I want to see.

>> I agree - all code sits on its' own merits and these components should not
>> (at least in base form) be integrated into the rest of Avalon. The
>> cornerstone CVS may integrate components from the catalog/agora CVS into
>> the Avalon services/kernel API but I don't see this as something the
>> catalog/agora should do by itself. 
>
>I see it the other way around - avalon components should be treated equal
>with components developed by other projects, and "promoted" based on
>their actual use in projects and user adoption.

Isn't that what I just said ? ;)

>Merging this project with avalon would sugest that avalon components are
>"special" compared with components from other project. And that would be
>wrong.

I am not sure where you get this impression - I hope I haven't given you
that impression. Even within Avalon we have had competing implementaions of
things. At one stage we had 3 different pooling frameworks, 3 different
schedulers and different server-socket abstractions. Merit determins which
ones last and which are burned away.

>> By opening another CVS and giving everybody karma/voting rights/whatever
>> then I  believe the community would manage itself ;) If you think it is a
>> bad idea to integrate with the framework part of Avalon then don't ;) I
>> would even allow components integrated with other frameworks be added (with
>> the proviso that they would be refactored to use JavaBeans standard
overtime).
>
>Again - I think it's the other way around. 
>
>Avalon components could be integrated in the library, if they are not
>dependent on a framework - and avalon decides to. 

When you say Avalon - what are you referring to exactly? If you are
referring to the frameowork components or cornerstone components then I
agree - if not then you are going to have to explain it further ;)
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

[David Weinrich <dw...@home.com>]

On Wed, 28 Feb 2001, Craig R. McClanahan wrote:

> Peter Donald wrote:
>
> > At 09:18  1/3/01 -0800, cmanolache@yahoo.com wrote:
> > >Arguing that this should be part of avalon because it overlaps with
> > >it's goal is wrong - the library will overlap with almost all
> > >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> > >with avalon ), it overlaps with alexandria. All jakarta
> > >projects are creating some forms of server-side compoents
> > >( including tomcat ).
> >
> > But Avalon was intended to be a shared repository of server-side components
> > - it has no other purpose ;) All the other projects create server-side
> > components as a side effect of developing another product. Avalons product
> > is the components.
> >
>
> Peter, when you say "components" here, I need a clarification.  Do you mean "a
> chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
> notion of a Component interface"?  These are two entirely different things.  If
> it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
> the latter, then that's just as presumptive as me saying it should live in Struts,
> or Jon saying it should live in Turbine (neither of which is happening).
>
> The shareable stuff I'm interested in is smaller than a framework --- any
> framework.
>

I agree with this completely. I also appreciate your presence and Remy's
presence on the list today as I think this is a pretty good indication
that we are making progress, and that the desire/need for this stuff exists in
jakarta-land. Thanks :)

David

> Craig McClanahan
>
>
>

Re: Riffing again on another tangent

[David Weinrich <dw...@home.com>]

On Wed, 28 Feb 2001, Craig R. McClanahan wrote:

> Peter Donald wrote:
>
> > At 09:18  1/3/01 -0800, cmanolache@yahoo.com wrote:
> > >Arguing that this should be part of avalon because it overlaps with
> > >it's goal is wrong - the library will overlap with almost all
> > >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> > >with avalon ), it overlaps with alexandria. All jakarta
> > >projects are creating some forms of server-side compoents
> > >( including tomcat ).
> >
> > But Avalon was intended to be a shared repository of server-side components
> > - it has no other purpose ;) All the other projects create server-side
> > components as a side effect of developing another product. Avalons product
> > is the components.
> >
>
> Peter, when you say "components" here, I need a clarification.  Do you mean "a
> chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
> notion of a Component interface"?  These are two entirely different things.  If
> it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
> the latter, then that's just as presumptive as me saying it should live in Struts,
> or Jon saying it should live in Turbine (neither of which is happening).
>
> The shareable stuff I'm interested in is smaller than a framework --- any
> framework.
>

I agree with this completely. I also appreciate your presence and Remy's
presence on the list today as I think this is a pretty good indication
that we are making progress, and that the desire/need for this stuff exists in
jakarta-land. Thanks :)

David

> Craig McClanahan
>
>
>

Re: Riffing again on another tangent

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Peter Donald wrote:

> At 09:18  1/3/01 -0800, cmanolache@yahoo.com wrote:
> >Arguing that this should be part of avalon because it overlaps with
> >it's goal is wrong - the library will overlap with almost all
> >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> >with avalon ), it overlaps with alexandria. All jakarta
> >projects are creating some forms of server-side compoents
> >( including tomcat ).
>
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
>

Peter, when you say "components" here, I need a clarification.  Do you mean "a
chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
notion of a Component interface"?  These are two entirely different things.  If
it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
the latter, then that's just as presumptive as me saying it should live in Struts,
or Jon saying it should live in Turbine (neither of which is happening).

The shareable stuff I'm interested in is smaller than a framework --- any
framework.

Craig McClanahan

Re: Riffing again on another tangent

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Peter Donald wrote:

> At 09:18  1/3/01 -0800, cmanolache@yahoo.com wrote:
> >Arguing that this should be part of avalon because it overlaps with
> >it's goal is wrong - the library will overlap with almost all
> >jakarta projects. It overlaps with jakarta-tools ( which also overlaps
> >with avalon ), it overlaps with alexandria. All jakarta
> >projects are creating some forms of server-side compoents
> >( including tomcat ).
>
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.
>

Peter, when you say "components" here, I need a clarification.  Do you mean "a
chunk of reusable code" or "a chunk of reusable code that implement's Avalon's
notion of a Component interface"?  These are two entirely different things.  If
it's the former, I'd still prefer agora/commons/whatever to be separate -- if it's
the latter, then that's just as presumptive as me saying it should live in Struts,
or Jon saying it should live in Turbine (neither of which is happening).

The shareable stuff I'm interested in is smaller than a framework --- any
framework.

Craig McClanahan

Re: Riffing again on another tangent

[cm...@yahoo.com]

> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.

Which is a very generic term - like saying the goal of a project is to
create java code, or a server-side templating system. 

What is specific about Avalon components ? All jakarta projects are
developing server-side software, and most of the good code is organized in
components. 

And if you are saying that Avalon was supposed to do what we want for the
libary - provide "catalog" and "common development" for projects - then it
obviously failed ( since jakarta projects are still duplicating code
instead of participating in avalon ) - so there is no point in discussing
this :-)
 

> I don't see how having two separate projects who do the same thing could be
> good for jakarta. Could you imagine if someone proposed another servlet
> engine at jakarta - Do you think that another servlet engine that served
> roughly the same purpose would be good for Jakarta? (I don't think so)
> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
> engine ? (perhaps they get associated with Apache).

Yes, that already happened and we survived. I would say ( IMHO !!) that
the net effect was quite good (!).

And Apache has 2 xml parsers, multiple template engines, multiple flavors
of regexps. Choice is good - each may be better suited for a different
environment ( like tomcat 3.x is the only solution for JDK1.1 and
catalina / 4.x for  people wanting servlet 2.3 support - to give only a
"neutral" example )


> I agree - all code sits on its' own merits and these components should not
> (at least in base form) be integrated into the rest of Avalon. The
> cornerstone CVS may integrate components from the catalog/agora CVS into
> the Avalon services/kernel API but I don't see this as something the
> catalog/agora should do by itself. 

I see it the other way around - avalon components should be treated equal
with components developed by other projects, and "promoted" based on
their actual use in projects and user adoption.

Merging this project with avalon would sugest that avalon components are
"special" compared with components from other project. And that would be
wrong.


> By opening another CVS and giving everybody karma/voting rights/whatever
> then I  believe the community would manage itself ;) If you think it is a
> bad idea to integrate with the framework part of Avalon then don't ;) I
> would even allow components integrated with other frameworks be added (with
> the proviso that they would be refactored to use JavaBeans standard overtime).

Again - I think it's the other way around. 

Avalon components could be integrated in the library, if they are not
dependent on a framework - and avalon decides to. 



Costin

Re: Riffing again on another tangent

[cm...@yahoo.com]

> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.

Which is a very generic term - like saying the goal of a project is to
create java code, or a server-side templating system. 

What is specific about Avalon components ? All jakarta projects are
developing server-side software, and most of the good code is organized in
components. 

And if you are saying that Avalon was supposed to do what we want for the
libary - provide "catalog" and "common development" for projects - then it
obviously failed ( since jakarta projects are still duplicating code
instead of participating in avalon ) - so there is no point in discussing
this :-)
 

> I don't see how having two separate projects who do the same thing could be
> good for jakarta. Could you imagine if someone proposed another servlet
> engine at jakarta - Do you think that another servlet engine that served
> roughly the same purpose would be good for Jakarta? (I don't think so)
> Would it be good for Tomcat ? (not really) Would it be good for foo servlet
> engine ? (perhaps they get associated with Apache).

Yes, that already happened and we survived. I would say ( IMHO !!) that
the net effect was quite good (!).

And Apache has 2 xml parsers, multiple template engines, multiple flavors
of regexps. Choice is good - each may be better suited for a different
environment ( like tomcat 3.x is the only solution for JDK1.1 and
catalina / 4.x for  people wanting servlet 2.3 support - to give only a
"neutral" example )


> I agree - all code sits on its' own merits and these components should not
> (at least in base form) be integrated into the rest of Avalon. The
> cornerstone CVS may integrate components from the catalog/agora CVS into
> the Avalon services/kernel API but I don't see this as something the
> catalog/agora should do by itself. 

I see it the other way around - avalon components should be treated equal
with components developed by other projects, and "promoted" based on
their actual use in projects and user adoption.

Merging this project with avalon would sugest that avalon components are
"special" compared with components from other project. And that would be
wrong.


> By opening another CVS and giving everybody karma/voting rights/whatever
> then I  believe the community would manage itself ;) If you think it is a
> bad idea to integrate with the framework part of Avalon then don't ;) I
> would even allow components integrated with other frameworks be added (with
> the proviso that they would be refactored to use JavaBeans standard overtime).

Again - I think it's the other way around. 

Avalon components could be integrated in the library, if they are not
dependent on a framework - and avalon decides to. 



Costin

Re: Riffing again on another tangent

[cm...@yahoo.com]

Well, sorry about the previous mail, it didn't sounded as I wanted.

All I'm trying to say is that the Library is significantly bigger than
Avalon - in both scope and intended community.

It does overap with avalon, as it overlaps with jakarta-tools or
alexandria - that doesn't mean it should be merged with any of those.

Costin

Re: Riffing again on another tangent

[cm...@yahoo.com]

Well, sorry about the previous mail, it didn't sounded as I wanted.

All I'm trying to say is that the Library is significantly bigger than
Avalon - in both scope and intended community.

It does overap with avalon, as it overlaps with jakarta-tools or
alexandria - that doesn't mean it should be merged with any of those.

Costin

Re: Riffing again on another tangent

[Peter Donald <do...@apache.org>]

At 09:18  1/3/01 -0800, cmanolache@yahoo.com wrote:
>Arguing that this should be part of avalon because it overlaps with
>it's goal is wrong - the library will overlap with almost all 
>jakarta projects. It overlaps with jakarta-tools ( which also overlaps
>with avalon ), it overlaps with alexandria. All jakarta 
>projects are creating some forms of server-side compoents 
>( including tomcat ).

But Avalon was intended to be a shared repository of server-side components
- it has no other purpose ;) All the other projects create server-side
components as a side effect of developing another product. Avalons product
is the components.

>BTW, the question is not what would be better for avalon, but
>what would be better for this project and jakarta. 

To be honest - my order of importance is;

* whats good for jakarta
* whats good for avalon
* whats good for library

I don't see how having two separate projects who do the same thing could be
good for jakarta. Could you imagine if someone proposed another servlet
engine at jakarta - Do you think that another servlet engine that served
roughly the same purpose would be good for Jakarta? (I don't think so)
Would it be good for Tomcat ? (not really) Would it be good for foo servlet
engine ? (perhaps they get associated with Apache).

>Another big problem ( and I'm very strong about it ) is that 
>by calling it avalon we'll have to deal with a way to
>position the existing avalon code - since it shouldn't be
>in any way "favorised" versus code from other projects.

I agree - all code sits on its' own merits and these components should not
(at least in base form) be integrated into the rest of Avalon. The
cornerstone CVS may integrate components from the catalog/agora CVS into
the Avalon services/kernel API but I don't see this as something the
catalog/agora should do by itself. 

By opening another CVS and giving everybody karma/voting rights/whatever
then I  believe the community would manage itself ;) If you think it is a
bad idea to integrate with the framework part of Avalon then don't ;) I
would even allow components integrated with other frameworks be added (with
the proviso that they would be refactored to use JavaBeans standard overtime).


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

[Peter Donald <do...@apache.org>]

At 09:18  1/3/01 -0800, cmanolache@yahoo.com wrote:
>Arguing that this should be part of avalon because it overlaps with
>it's goal is wrong - the library will overlap with almost all 
>jakarta projects. It overlaps with jakarta-tools ( which also overlaps
>with avalon ), it overlaps with alexandria. All jakarta 
>projects are creating some forms of server-side compoents 
>( including tomcat ).

But Avalon was intended to be a shared repository of server-side components
- it has no other purpose ;) All the other projects create server-side
components as a side effect of developing another product. Avalons product
is the components.

>BTW, the question is not what would be better for avalon, but
>what would be better for this project and jakarta. 

To be honest - my order of importance is;

* whats good for jakarta
* whats good for avalon
* whats good for library

I don't see how having two separate projects who do the same thing could be
good for jakarta. Could you imagine if someone proposed another servlet
engine at jakarta - Do you think that another servlet engine that served
roughly the same purpose would be good for Jakarta? (I don't think so)
Would it be good for Tomcat ? (not really) Would it be good for foo servlet
engine ? (perhaps they get associated with Apache).

>Another big problem ( and I'm very strong about it ) is that 
>by calling it avalon we'll have to deal with a way to
>position the existing avalon code - since it shouldn't be
>in any way "favorised" versus code from other projects.

I agree - all code sits on its' own merits and these components should not
(at least in base form) be integrated into the rest of Avalon. The
cornerstone CVS may integrate components from the catalog/agora CVS into
the Avalon services/kernel API but I don't see this as something the
catalog/agora should do by itself. 

By opening another CVS and giving everybody karma/voting rights/whatever
then I  believe the community would manage itself ;) If you think it is a
bad idea to integrate with the framework part of Avalon then don't ;) I
would even allow components integrated with other frameworks be added (with
the proviso that they would be refactored to use JavaBeans standard overtime).


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

[Ted Husted <ne...@husted.com>]

Peter Donald wrote:
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?"). I was also mailed off list with two other
> things that Avalon could be interpreted as being - so I guess when you say
> "Avalon" you have to qualify it which particular component ;)

Peter Donald wrote:
> Avalon is;
> 1. A repository of general utility code
> 2. A repository of patterns and framework code
> 3. A set of general utility code based on (2)
> 4. A micro kernel for running services
> 5. A set of services that are orientated towards server environments

Peter Donald wrote:
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.

And in the spirit of cooperation ;-) I'd suggest that since Avalon has
so much on its plate already, why not try and offload (1) to the
Commons, and concentrate more fully on (2) through (5)+.

Peter Donald wrote:
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.

Even with the reorganization, I think the perception is going to be that
Avalon is a framework product that also offers up some general utility
code, the same way Struts and Turbine do. 

The difference between Avalon and the Commons is that Avalon is trying
to put the pieces together, and the Commons is really offering pieces,
only pieces, and nothing but pieces. BYOP - bring your own puzzle ;-) 

-T.

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Peter Donald wrote:
> Not necessarily ;) Avalon is a name with many faces. We are trying to
> separate out each of these at the moment but we are still no there. I
> posted a list of 5 things I though Avalon was on general@jakarta (under
> subject "What is Avalon?"). I was also mailed off list with two other
> things that Avalon could be interpreted as being - so I guess when you say
> "Avalon" you have to qualify it which particular component ;)

Peter Donald wrote:
> Avalon is;
> 1. A repository of general utility code
> 2. A repository of patterns and framework code
> 3. A set of general utility code based on (2)
> 4. A micro kernel for running services
> 5. A set of services that are orientated towards server environments

Peter Donald wrote:
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.

And in the spirit of cooperation ;-) I'd suggest that since Avalon has
so much on its plate already, why not try and offload (1) to the
Commons, and concentrate more fully on (2) through (5)+.

Peter Donald wrote:
> But Avalon was intended to be a shared repository of server-side components
> - it has no other purpose ;) All the other projects create server-side
> components as a side effect of developing another product. Avalons product
> is the components.

Even with the reorganization, I think the perception is going to be that
Avalon is a framework product that also offers up some general utility
code, the same way Struts and Turbine do. 

The difference between Avalon and the Commons is that Avalon is trying
to put the pieces together, and the Commons is really offering pieces,
only pieces, and nothing but pieces. BYOP - bring your own puzzle ;-) 

-T.

Re: Riffing again on another tangent

[cm...@yahoo.com]

> >Beeing "project-neutral" is important to create what we need.
> 
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.

Peter,

Beeing project-neutral is very important. 

We shouldn't treat the components developed in avalon in a special 
way - the fact is that _all_ jakarta projects are creating server-side
components.

Arguing that this should be part of avalon because it overlaps with
it's goal is wrong - the library will overlap with almost all 
jakarta projects. It overlaps with jakarta-tools ( which also overlaps
with avalon ), it overlaps with alexandria. All jakarta 
projects are creating some forms of server-side compoents 
( including tomcat ).

In the end, what matters is what we gain and loose by calling it Avalon.
I think we loose much more than we gain. The only thing we might
gain is avoiding confusion - but that shouldn't be the driving 
argument, in any case. ( and there is alreay enough confusion
surrounding avalon ).

BTW, the question is not what would be better for avalon, but
what would be better for this project and jakarta. 

Another big problem ( and I'm very strong about it ) is that 
by calling it avalon we'll have to deal with a way to
position the existing avalon code - since it shouldn't be
in any way "favorised" versus code from other projects.

Costin


 

Re: Riffing again on another tangent

[cm...@yahoo.com]

> >Beeing "project-neutral" is important to create what we need.
> 
> This would be the only sticking point I see. It is unfortunate that other
> projects are seen as "competitors" rather than "companions" but I guess
> until this is "fixed" it could be an issue. However instead of starting
> again I would prefer that we try to start fixing things now.

Peter,

Beeing project-neutral is very important. 

We shouldn't treat the components developed in avalon in a special 
way - the fact is that _all_ jakarta projects are creating server-side
components.

Arguing that this should be part of avalon because it overlaps with
it's goal is wrong - the library will overlap with almost all 
jakarta projects. It overlaps with jakarta-tools ( which also overlaps
with avalon ), it overlaps with alexandria. All jakarta 
projects are creating some forms of server-side compoents 
( including tomcat ).

In the end, what matters is what we gain and loose by calling it Avalon.
I think we loose much more than we gain. The only thing we might
gain is avoiding confusion - but that shouldn't be the driving 
argument, in any case. ( and there is alreay enough confusion
surrounding avalon ).

BTW, the question is not what would be better for avalon, but
what would be better for this project and jakarta. 

Another big problem ( and I'm very strong about it ) is that 
by calling it avalon we'll have to deal with a way to
position the existing avalon code - since it shouldn't be
in any way "favorised" versus code from other projects.

Costin


 

Re: Riffing again on another tangent

[Peter Donald <do...@apache.org>]

At 04:01  1/3/01 -0800, cmanolache@yahoo.com 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.
>
>The proposed project ( library/directory/agora/whatever ) is indeed
>similar with avalon in one of the goals - creating server side components.
>( and also to jakarta-tools )

ie Avalon has identical content but ...

>But IMHO the current proposal is closer to alexandria then avalon.
>
>But what's special about the library/agora is that it proposes to 
>act as a common repository, managed in common by multiple projects. While
>creating productized components is also a goal ( same as in Avalon ), the
>sharing of components and inter-project dynamics are more important.
From this point of view, avalon is one of the projects that will share
>components - equal with all other projects where general-purpose code is
>developed.

different infrastructure. Since I think the infrastructure we create
will/should be integrated into all projects - what will happen when we
integrate it into Avalon? We will have two identical projects.

>Beeing "project-neutral" is important to create what we need.

This would be the only sticking point I see. It is unfortunate that other
projects are seen as "competitors" rather than "companions" but I guess
until this is "fixed" it could be an issue. However instead of starting
again I would prefer that we try to start fixing things now.

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

["Geir Magnusson Jr." <ge...@optonline.net>]

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.

With the big exception of the productized components, Avalon is
completely separate from Lib, Dir, Ag.  But you are right, one of the
[many :)] interpretations of Avalon could be that of hosting productized
components.

I just thought that having a directory of 'stuff' so people (internal to
Jakarta as well as, and maybe more importantly outsiders) can find
things is important - the recognition of the richness of the Jakarta
codebases is what got me started on this in the first place..
 
> 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 am all for jakarta-avalon-dbpool as long as its separable from Avalon
in build, documentation and independence of purpose. By this I mean that
the dbpool can primarily implement standard JDBC-compliant interfaces
and conventions, and is not required to fit into the Avalon-patterns or
framework.

I think it would be great to house it there - if avalon turns out to be
what I want library to be, you'll see me there :)

> I'd like to hear consensus with someone representing jakarta-avalon (i.e.,
> Peter Donald) before creating another subproject with overlapping goals.
> 
> - Sam Ruby

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Riffing again on another tangent

[Peter Donald <do...@apache.org>]

At 04:01  1/3/01 -0800, cmanolache@yahoo.com 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.
>
>The proposed project ( library/directory/agora/whatever ) is indeed
>similar with avalon in one of the goals - creating server side components.
>( and also to jakarta-tools )

ie Avalon has identical content but ...

>But IMHO the current proposal is closer to alexandria then avalon.
>
>But what's special about the library/agora is that it proposes to 
>act as a common repository, managed in common by multiple projects. While
>creating productized components is also a goal ( same as in Avalon ), the
>sharing of components and inter-project dynamics are more important.
>From this point of view, avalon is one of the projects that will share
>components - equal with all other projects where general-purpose code is
>developed.

different infrastructure. Since I think the infrastructure we create
will/should be integrated into all projects - what will happen when we
integrate it into Avalon? We will have two identical projects.

>Beeing "project-neutral" is important to create what we need.

This would be the only sticking point I see. It is unfortunate that other
projects are seen as "competitors" rather than "companions" but I guess
until this is "fixed" it could be an issue. However instead of starting
again I would prefer that we try to start fixing things now.

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

[Ted Husted <ne...@husted.com>]

cmanolache@yahoo.com wrote:
> But what's special about the library/agora is that it proposes to
> act as a common repository, managed in common by multiple projects. While
> creating productized components is also a goal ( same as in Avalon ), the
> sharing of components and inter-project dynamics are more important.

I think it's important to mention that which facility of the Library is
most important is a matter of viewpoint. 

Costin believes the sandbox is most important, since it will give
committers from different subprojects a chance to share code. 

Geir believes creating and maintaining independent packages is most
important, since it will made the codebases available to more users,
including the other Jakarta subprojects.

Ted believes the catalog is most important, since it will bring a lot
packages to the surface, so that they can be used and improved. 

In practice, I believe there will be synergy between the facilities, and
there will a lot more serendipity before we are through.

-T.

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

cmanolache@yahoo.com wrote:
> But what's special about the library/agora is that it proposes to
> act as a common repository, managed in common by multiple projects. While
> creating productized components is also a goal ( same as in Avalon ), the
> sharing of components and inter-project dynamics are more important.

I think it's important to mention that which facility of the Library is
most important is a matter of viewpoint. 

Costin believes the sandbox is most important, since it will give
committers from different subprojects a chance to share code. 

Geir believes creating and maintaining independent packages is most
important, since it will made the codebases available to more users,
including the other Jakarta subprojects.

Ted believes the catalog is most important, since it will bring a lot
packages to the surface, so that they can be used and improved. 

In practice, I believe there will be synergy between the facilities, and
there will a lot more serendipity before we are through.

-T.

Re: Riffing again on another tangent

[David Weinrich <dw...@home.com>]

On Thu, 1 Mar 2001 cmanolache@yahoo.com 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.
>
> The proposed project ( library/directory/agora/whatever ) is indeed
> similar with avalon in one of the goals - creating server side components.
> ( and also to jakarta-tools )
>
> But IMHO the current proposal is closer to alexandria then avalon.
>
> But what's special about the library/agora is that it proposes to
> act as a common repository, managed in common by multiple projects. While
> creating productized components is also a goal ( same as in Avalon ), the
> sharing of components and inter-project dynamics are more important.
> >From this point of view, avalon is one of the projects that will share
> components - equal with all other projects where general-purpose code is
> developed.
>
> > 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.
>
> If the goal would be to create a dbpool, maybe.
>
> But we want to a way to collect, catalog and share multiple dbpools, and
> eventually productize the best ones. Creating a new repository for each
> component is not a good idea.
>
>
> > I'd like to hear consensus with someone representing jakarta-avalon (i.e.,
> > Peter Donald) before creating another subproject with overlapping goals.
>
> I think the library's goal is to overlap with all jakarta projects :-)
> And we'll need a bigger consensus - i.e. most jakarta projects should
> participate in order for this to be a success.
>
> Beeing "project-neutral" is important to create what we need.
>

This seems to be a key point, I would say it is essential to create what
we need :)

> Costin
>
>

David

Re: Riffing again on another tangent

[David Weinrich <dw...@home.com>]

On Thu, 1 Mar 2001 cmanolache@yahoo.com 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.
>
> The proposed project ( library/directory/agora/whatever ) is indeed
> similar with avalon in one of the goals - creating server side components.
> ( and also to jakarta-tools )
>
> But IMHO the current proposal is closer to alexandria then avalon.
>
> But what's special about the library/agora is that it proposes to
> act as a common repository, managed in common by multiple projects. While
> creating productized components is also a goal ( same as in Avalon ), the
> sharing of components and inter-project dynamics are more important.
> >From this point of view, avalon is one of the projects that will share
> components - equal with all other projects where general-purpose code is
> developed.
>
> > 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.
>
> If the goal would be to create a dbpool, maybe.
>
> But we want to a way to collect, catalog and share multiple dbpools, and
> eventually productize the best ones. Creating a new repository for each
> component is not a good idea.
>
>
> > I'd like to hear consensus with someone representing jakarta-avalon (i.e.,
> > Peter Donald) before creating another subproject with overlapping goals.
>
> I think the library's goal is to overlap with all jakarta projects :-)
> And we'll need a bigger consensus - i.e. most jakarta projects should
> participate in order for this to be a success.
>
> Beeing "project-neutral" is important to create what we need.
>

This seems to be a key point, I would say it is essential to create what
we need :)

> Costin
>
>

David

Re: Riffing again on another tangent

[cm...@yahoo.com]

> > 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.

The proposed project ( library/directory/agora/whatever ) is indeed
similar with avalon in one of the goals - creating server side components.
( and also to jakarta-tools )

But IMHO the current proposal is closer to alexandria then avalon.

But what's special about the library/agora is that it proposes to 
act as a common repository, managed in common by multiple projects. While
creating productized components is also a goal ( same as in Avalon ), the
sharing of components and inter-project dynamics are more important.

Re: Riffing again on another tangent

[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

[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

["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

["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

[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

[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

["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

["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

["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

["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

[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

[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

["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

["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

[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

[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

["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

["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

[David Weinrich <dw...@home.com>]

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

[David Weinrich <dw...@home.com>]

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

[cm...@yahoo.com]

> > 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.

The proposed project ( library/directory/agora/whatever ) is indeed
similar with avalon in one of the goals - creating server side components.
( and also to jakarta-tools )

But IMHO the current proposal is closer to alexandria then avalon.

But what's special about the library/agora is that it proposes to 
act as a common repository, managed in common by multiple projects. While
creating productized components is also a goal ( same as in Avalon ), the
sharing of components and inter-project dynamics are more important.

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Morgan Delagrange wrote:
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?

Incidentally, I plugged Morgan's JDBC tags into my current Struts
project last night. His tag supports a connection through a standard
Javax datasource, and the Struts pool exposes itself that way via the
application context. They hooked up smooth as silk, and I'm a very happy
camper right now! 

-Ted.

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Remy Maucherat wrote:
> I would be willing to contribute (if someone is interested, of course) the
> Slide HTTP client library core to the library / agora project if there are
> some very strict publicized guidelines about API and behavior changes (I
> have quite a bit of code which depends on the library). I would suggest
> asking for a vote with no -1 prior to any change which would break source
> compatibility.

Welcome aboard, Remy!

The guidelines we have so far at at 

< http://husted.com/about/jakarta/lib003.htm >

The index page for the proposal is at 

< http://husted.com/about/jakarta/library.html >

And most of the list is archived at mail-archive.com.

-T.

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Remy Maucherat wrote:
> I would be willing to contribute (if someone is interested, of course) the
> Slide HTTP client library core to the library / agora project if there are
> some very strict publicized guidelines about API and behavior changes (I
> have quite a bit of code which depends on the library). I would suggest
> asking for a vote with no -1 prior to any change which would break source
> compatibility.

Welcome aboard, Remy!

The guidelines we have so far at at 

< http://husted.com/about/jakarta/lib003.htm >

The index page for the proposal is at 

< http://husted.com/about/jakarta/library.html >

And most of the list is archived at mail-archive.com.

-T.

Re: Riffing again on another tangent

[Remy Maucherat <re...@eng.sun.com>]

> The shareable thingies that I care the most about are typically smaller
> than a framework.  In fact, dependency on a particular framework (of any
> nature) is probably detrimental to reuse.
>
> Example 1:  the connection pool in Struts is 2 classes, with
> dependencies only on the JDK and the JDBC 2.0 Optional Package APIs.  It
> uses JavaBeans property setters for configuration, so you'd write your
> own mechanism for initialization (using whatever approach your framework
> favors), but the pool itself doesn't mandate anything.

I think that is the ideal case for shared components :
- support existing standards, if that is applicable (javax.sql.DataSource
for a DB pool)
- no dependency on a larger framework
The Struts db pool looks like it's the best one overall.

I would be willing to contribute (if someone is interested, of course) the
Slide HTTP client library core to the library / agora project if there are
some very strict publicized guidelines about API and behavior changes (I
have quite a bit of code which depends on the library). I would suggest
asking for a vote with no -1 prior to any change which would break source
compatibility.
I didn't follow the whole discussion so this may have been discussed already
(Costin just convinced me I should join the effort).

I would vote +1 for the Agora name.

> +1 on fine-grained JAR files -- this is one of the better parts of the
> CPAN approach.

+1 too.

> When we get down to process details, I'm going to recommend that we
> record dependencies in the MANIFEST.MF file of our JAR files, in the
> manner recommended in the JDK 1.3 documentation describing "system
> extensions".  In suitable environments (for instance, any servlet
> container that implements 2.3), the container will even do this checking
> for you.

Sure, but let's not seal the JARs ;-)

> > The Library project should specifically steer clear of
> > developing grand frameworks.  That kind of development
> > is much more appropriate for full-blown subprojects
> > like Turbine, Struts, and Avalon.

+1.

Remy

Re: Riffing again on another tangent

[Remy Maucherat <re...@eng.sun.com>]

> The shareable thingies that I care the most about are typically smaller
> than a framework.  In fact, dependency on a particular framework (of any
> nature) is probably detrimental to reuse.
>
> Example 1:  the connection pool in Struts is 2 classes, with
> dependencies only on the JDK and the JDBC 2.0 Optional Package APIs.  It
> uses JavaBeans property setters for configuration, so you'd write your
> own mechanism for initialization (using whatever approach your framework
> favors), but the pool itself doesn't mandate anything.

I think that is the ideal case for shared components :
- support existing standards, if that is applicable (javax.sql.DataSource
for a DB pool)
- no dependency on a larger framework
The Struts db pool looks like it's the best one overall.

I would be willing to contribute (if someone is interested, of course) the
Slide HTTP client library core to the library / agora project if there are
some very strict publicized guidelines about API and behavior changes (I
have quite a bit of code which depends on the library). I would suggest
asking for a vote with no -1 prior to any change which would break source
compatibility.
I didn't follow the whole discussion so this may have been discussed already
(Costin just convinced me I should join the effort).

I would vote +1 for the Agora name.

> +1 on fine-grained JAR files -- this is one of the better parts of the
> CPAN approach.

+1 too.

> When we get down to process details, I'm going to recommend that we
> record dependencies in the MANIFEST.MF file of our JAR files, in the
> manner recommended in the JDK 1.3 documentation describing "system
> extensions".  In suitable environments (for instance, any servlet
> container that implements 2.3), the container will even do this checking
> for you.

Sure, but let's not seal the JARs ;-)

> > The Library project should specifically steer clear of
> > developing grand frameworks.  That kind of development
> > is much more appropriate for full-blown subprojects
> > like Turbine, Struts, and Avalon.

+1.

Remy

Re: Riffing again on another tangent

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Morgan Delagrange wrote:

> --- Sam Ruby <ru...@us.ibm.com> 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.
>
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
>
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
>
> 1) Different charters
>
> Avalon's charter is:
>
>   The Avalon project is an effort to create,
>   design, develop and maintain a common
>   framework for server applications written
>   using the Java language. This framework will
>   not be a standalone product, but will allow
>   existing and yet to be created server
>   applications to fit into a common platform
>   and to share code, design and human resources.
>
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.
>

I think this is the key distinction.  I've lurked on the avalon
developer's list off and on, and this seems to have been the primary
focus.

>
> The Library project is quite different.  It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function.  More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)
>

The shareable thingies that I care the most about are typically smaller
than a framework.  In fact, dependency on a particular framework (of any
nature) is probably detrimental to reuse.

Example 1:  the connection pool in Struts is 2 classes, with
dependencies only on the JDK and the JDBC 2.0 Optional Package APIs.  It
uses JavaBeans property setters for configuration, so you'd write your
own mechanism for initialization (using whatever approach your framework
favors), but the pool itself doesn't mandate anything.

Example 2:  The BeanUtils/ConvertUtils/PropertyUtils classes in Struts
are just a bunch of publicly available methods that work together for
introspecting JavaBeans.  They rely only on JDK APIs, and have no
connection to any sort of probramming model.

>
> 2) Different organization
>
> Our intention with Library is to make each component a
> microcosm within the Library subproject.  A component
> has its own documentation, including FAQ, quick start
> guide, etc.  It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs.  This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.
>

+1 on fine-grained JAR files -- this is one of the better parts of the
CPAN approach.

When we get down to process details, I'm going to recommend that we
record dependencies in the MANIFEST.MF file of our JAR files, in the
manner recommended in the JDK 1.3 documentation describing "system
extensions".  In suitable environments (for instance, any servlet
container that implements 2.3), the container will even do this checking
for you.

>
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?
>
> Turbine seems like the wrong choice.  Where is the
> documentation for the dbPool?  Is it adequate on its
> own, or will the taglib implementer have to configure
> lots of unrelated Turbine functionality as well?  I'm
> also somewhat uncomfortable pointing people to the
> Turbine project, many of whose members are anti-JSP
> and therefore anti-Taglib.  The last thing I want is
> for users to be met with condescension when they ask
> the Turbine mailing list for help, which is quite
> possible in the current political climate.
>
> Struts is probably more appropriate, but it's still
> one big JAR.  It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental.  It's a good
> implementation, but it's a little buried within the
> website.  In face it's not obvious to the uninitiated
> that their database pool even exists.
>

In order to be usefully shared, the dbpool should be in a separate JAR
as you recommended earlier.

>
> So, I guess I could go to Avalon and ask them to
> implement a database pool, but I'm still faced with
> the same old questions.  How much of the database pool
> is going to be tied up in the Avalon framework?  How
> self-contained will the documentation and
> implementation be?  Who's going to write it?
>
> This is a specific example, which to me underscores
> the need for a framework-independent repository of
> mini-subprojects.
>
> 3) Different scope
>
> The Library project should specifically steer clear of
> developing grand frameworks.  That kind of development
> is much more appropriate for full-blown subprojects
> like Turbine, Struts, and Avalon.
>

Agreed ... see comments above.

>
> 4) Convergent goals
>
> When possible, other frameworks can plug Library
> components into their framework.  The Library project
> is not intended to be a replacement to Avalong, Struts
> or Turbine.  Rather it's a place for convergence,
> where they can farm out self-contained components and
> focus on the means for tying them together.
>
> In some cases, a component may be able to be
> completely external to the project.  For example,
> perhaps Struts does not really need to reference
> directly the database pooling code, if it can still
> grab connections from a JNDI DataSource or a pooling
> Driver.  Then we've really reached Nirvana, components
> with interfaces so clean that we can literatlly swap
> implementations in and out at will.
>
> As long as we focus exclusively on frameworks, I think
> it will be very difficult to reach these ends.
>
> - Morgan
>

Craig

Re: Riffing again on another tangent

["Geir Magnusson Jr." <ge...@optonline.net>]

Morgan Delagrange wrote:
> 
> --- Sam Ruby <ru...@us.ibm.com> wrote:

> > I'd like to hear consensus with someone representing
> > jakarta-avalon (i.e.,
> > Peter Donald) before creating another subproject
> > with overlapping goals.
> 
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
> 
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
> 
> 1) Different charters
> 
> Avalon's charter is:
> 
>   The Avalon project is an effort to create,
>   design, develop and maintain a common
>   framework for server applications written
>   using the Java language. This framework will
>   not be a standalone product, but will allow
>   existing and yet to be created server
>   applications to fit into a common platform
>   and to share code, design and human resources.
> 
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.

I made that mistake too :-)

It appears that is their 'cover charter'.  Their *real* charter is
something else :D

Peter will chime in shortly, I assume.

> The Library project is quite different.  It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function.  More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)

+1
 
> 2) Different organization
> 
> Our intention with Library is to make each component a
> microcosm within the Library subproject.  A component
> has its own documentation, including FAQ, quick start
> guide, etc.  It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs.  This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.

+1
 
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?

Struts'.  All you JSP weirdo's should stay 'over there' ;)
 
> Turbine seems like the wrong choice. 
> [SNIP]
> 
> Struts is probably more appropriate, but it's still
> one big JAR.  It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental.  It's a good
> implementation, but it's a little buried within the
> website.  In face it's not obvious to the uninitiated
> that their database pool even exists.

BINGO.  This is *exactly* the same thinking that motivated me to start
persuing this.  I needed a DBCP, I saw that Turbine's was really
tailored for turbine [which is fine - it is what the need and want], I
saw that Struts' was more what I needed interface-wise, but still buried
in Struts, so I wanted to pull out Struts', steal ideas from Turbine,
document and ...

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Riffing again on another tangent

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Morgan Delagrange wrote:

> --- Sam Ruby <ru...@us.ibm.com> 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.
>
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
>
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
>
> 1) Different charters
>
> Avalon's charter is:
>
>   The Avalon project is an effort to create,
>   design, develop and maintain a common
>   framework for server applications written
>   using the Java language. This framework will
>   not be a standalone product, but will allow
>   existing and yet to be created server
>   applications to fit into a common platform
>   and to share code, design and human resources.
>
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.
>

I think this is the key distinction.  I've lurked on the avalon
developer's list off and on, and this seems to have been the primary
focus.

>
> The Library project is quite different.  It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function.  More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)
>

The shareable thingies that I care the most about are typically smaller
than a framework.  In fact, dependency on a particular framework (of any
nature) is probably detrimental to reuse.

Example 1:  the connection pool in Struts is 2 classes, with
dependencies only on the JDK and the JDBC 2.0 Optional Package APIs.  It
uses JavaBeans property setters for configuration, so you'd write your
own mechanism for initialization (using whatever approach your framework
favors), but the pool itself doesn't mandate anything.

Example 2:  The BeanUtils/ConvertUtils/PropertyUtils classes in Struts
are just a bunch of publicly available methods that work together for
introspecting JavaBeans.  They rely only on JDK APIs, and have no
connection to any sort of probramming model.

>
> 2) Different organization
>
> Our intention with Library is to make each component a
> microcosm within the Library subproject.  A component
> has its own documentation, including FAQ, quick start
> guide, etc.  It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs.  This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.
>

+1 on fine-grained JAR files -- this is one of the better parts of the
CPAN approach.

When we get down to process details, I'm going to recommend that we
record dependencies in the MANIFEST.MF file of our JAR files, in the
manner recommended in the JDK 1.3 documentation describing "system
extensions".  In suitable environments (for instance, any servlet
container that implements 2.3), the container will even do this checking
for you.

>
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?
>
> Turbine seems like the wrong choice.  Where is the
> documentation for the dbPool?  Is it adequate on its
> own, or will the taglib implementer have to configure
> lots of unrelated Turbine functionality as well?  I'm
> also somewhat uncomfortable pointing people to the
> Turbine project, many of whose members are anti-JSP
> and therefore anti-Taglib.  The last thing I want is
> for users to be met with condescension when they ask
> the Turbine mailing list for help, which is quite
> possible in the current political climate.
>
> Struts is probably more appropriate, but it's still
> one big JAR.  It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental.  It's a good
> implementation, but it's a little buried within the
> website.  In face it's not obvious to the uninitiated
> that their database pool even exists.
>

In order to be usefully shared, the dbpool should be in a separate JAR
as you recommended earlier.

>
> So, I guess I could go to Avalon and ask them to
> implement a database pool, but I'm still faced with
> the same old questions.  How much of the database pool
> is going to be tied up in the Avalon framework?  How
> self-contained will the documentation and
> implementation be?  Who's going to write it?
>
> This is a specific example, which to me underscores
> the need for a framework-independent repository of
> mini-subprojects.
>
> 3) Different scope
>
> The Library project should specifically steer clear of
> developing grand frameworks.  That kind of development
> is much more appropriate for full-blown subprojects
> like Turbine, Struts, and Avalon.
>

Agreed ... see comments above.

>
> 4) Convergent goals
>
> When possible, other frameworks can plug Library
> components into their framework.  The Library project
> is not intended to be a replacement to Avalong, Struts
> or Turbine.  Rather it's a place for convergence,
> where they can farm out self-contained components and
> focus on the means for tying them together.
>
> In some cases, a component may be able to be
> completely external to the project.  For example,
> perhaps Struts does not really need to reference
> directly the database pooling code, if it can still
> grab connections from a JNDI DataSource or a pooling
> Driver.  Then we've really reached Nirvana, components
> with interfaces so clean that we can literatlly swap
> implementations in and out at will.
>
> As long as we focus exclusively on frameworks, I think
> it will be very difficult to reach these ends.
>
> - Morgan
>

Craig

Re: Riffing again on another tangent

[Ted Husted <ne...@husted.com>]

Morgan Delagrange wrote:
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?

Incidentally, I plugged Morgan's JDBC tags into my current Struts
project last night. His tag supports a connection through a standard
Javax datasource, and the Struts pool exposes itself that way via the
application context. They hooked up smooth as silk, and I'm a very happy
camper right now! 

-Ted.

Re: Riffing again on another tangent

["Geir Magnusson Jr." <ge...@optonline.net>]

Morgan Delagrange wrote:
> 
> --- Sam Ruby <ru...@us.ibm.com> wrote:

> > I'd like to hear consensus with someone representing
> > jakarta-avalon (i.e.,
> > Peter Donald) before creating another subproject
> > with overlapping goals.
> 
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
> 
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
> 
> 1) Different charters
> 
> Avalon's charter is:
> 
>   The Avalon project is an effort to create,
>   design, develop and maintain a common
>   framework for server applications written
>   using the Java language. This framework will
>   not be a standalone product, but will allow
>   existing and yet to be created server
>   applications to fit into a common platform
>   and to share code, design and human resources.
> 
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.

I made that mistake too :-)

It appears that is their 'cover charter'.  Their *real* charter is
something else :D

Peter will chime in shortly, I assume.

> The Library project is quite different.  It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function.  More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)

+1
 
> 2) Different organization
> 
> Our intention with Library is to make each component a
> microcosm within the Library subproject.  A component
> has its own documentation, including FAQ, quick start
> guide, etc.  It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs.  This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.

+1
 
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?

Struts'.  All you JSP weirdo's should stay 'over there' ;)
 
> Turbine seems like the wrong choice. 
> [SNIP]
> 
> Struts is probably more appropriate, but it's still
> one big JAR.  It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental.  It's a good
> implementation, but it's a little buried within the
> website.  In face it's not obvious to the uninitiated
> that their database pool even exists.

BINGO.  This is *exactly* the same thinking that motivated me to start
persuing this.  I needed a DBCP, I saw that Turbine's was really
tailored for turbine [which is fine - it is what the need and want], I
saw that Struts' was more what I needed interface-wise, but still buried
in Struts, so I wanted to pull out Struts', steal ideas from Turbine,
document and ...

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Woops!

[Peter Donald <do...@apache.org>]

At 04:04  28/2/01 -0800, David Weinrich wrote:
>> I understand it this way too. A not-totally related point is, if it takes
>> more than a few of us more than a few days of digging to really nail down
>> exactly what Avalon is, would it be reasonable to expect a first time
>> visitor to Avalon to understand it as a place to get individual
>> components?
>>
>
>After sending this off I realized that this could be interpreted as a
>criticism of Avalon, which I hadn't intended when I wrote this. Please
>accept my apologies ( the Avalon team in general and also Peter
>specifically, your work/contributions are key to this
>discusssion/project ) for wording this in a pretty poor way :).

Naah theres plenty wrong with Avalon (plenty right aswell) and your
criticism is very mild compared to some of the attacks recently ;)

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: Woops!

[Peter Donald <do...@apache.org>]

At 04:04  28/2/01 -0800, David Weinrich wrote:
>> I understand it this way too. A not-totally related point is, if it takes
>> more than a few of us more than a few days of digging to really nail down
>> exactly what Avalon is, would it be reasonable to expect a first time
>> visitor to Avalon to understand it as a place to get individual
>> components?
>>
>
>After sending this off I realized that this could be interpreted as a
>criticism of Avalon, which I hadn't intended when I wrote this. Please
>accept my apologies ( the Avalon team in general and also Peter
>specifically, your work/contributions are key to this
>discusssion/project ) for wording this in a pretty poor way :).

Naah theres plenty wrong with Avalon (plenty right aswell) and your
criticism is very mild compared to some of the attacks recently ;)

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               |
*-----------------------------------------------------*

Woops!

[David Weinrich <dw...@home.com>]

On Wed, 28 Feb 2001, David Weinrich wrote:

>
>
> On Wed, 28 Feb 2001, Morgan Delagrange wrote:
>
> ...snipped here to prevent filling up your mailbox with duplicate stuff...
>
> >
> > Hmm, it would be a damn shame to shoot down the
> > library project after making so much progress.
> >
> > Here's my analysis of Avalon vs. Library, with a
> > little Turbine and Struts sprinkled in for good
> > measure.
> >
> > 1) Different charters
> >
> > Avalon's charter is:
> >
> >   The Avalon project is an effort to create,
> >   design, develop and maintain a common
> >   framework for server applications written
> >   using the Java language. This framework will
> >   not be a standalone product, but will allow
> >   existing and yet to be created server
> >   applications to fit into a common platform
> >   and to share code, design and human resources.
> >
> > Note that Avalon is a _framework_ for servers, which
> > is clear from the API's many interfaces for request,
> > responses, pools, properties, etc.
>
> I understand it this way too. A not-totally related point is, if it takes
> more than a few of us more than a few days of digging to really nail down
> exactly what Avalon is, would it be reasonable to expect a first time
> visitor to Avalon to understand it as a place to get individual
> components?
>

After sending this off I realized that this could be interpreted as a
criticism of Avalon, which I hadn't intended when I wrote this. Please
accept my apologies ( the Avalon team in general and also Peter
specifically, your work/contributions are key to this
discusssion/project ) for wording this in a pretty poor way :).

Woops!

[David Weinrich <dw...@home.com>]

On Wed, 28 Feb 2001, David Weinrich wrote:

>
>
> On Wed, 28 Feb 2001, Morgan Delagrange wrote:
>
> ...snipped here to prevent filling up your mailbox with duplicate stuff...
>
> >
> > Hmm, it would be a damn shame to shoot down the
> > library project after making so much progress.
> >
> > Here's my analysis of Avalon vs. Library, with a
> > little Turbine and Struts sprinkled in for good
> > measure.
> >
> > 1) Different charters
> >
> > Avalon's charter is:
> >
> >   The Avalon project is an effort to create,
> >   design, develop and maintain a common
> >   framework for server applications written
> >   using the Java language. This framework will
> >   not be a standalone product, but will allow
> >   existing and yet to be created server
> >   applications to fit into a common platform
> >   and to share code, design and human resources.
> >
> > Note that Avalon is a _framework_ for servers, which
> > is clear from the API's many interfaces for request,
> > responses, pools, properties, etc.
>
> I understand it this way too. A not-totally related point is, if it takes
> more than a few of us more than a few days of digging to really nail down
> exactly what Avalon is, would it be reasonable to expect a first time
> visitor to Avalon to understand it as a place to get individual
> components?
>

After sending this off I realized that this could be interpreted as a
criticism of Avalon, which I hadn't intended when I wrote this. Please
accept my apologies ( the Avalon team in general and also Peter
specifically, your work/contributions are key to this
discusssion/project ) for wording this in a pretty poor way :).

Re: Riffing again on another tangent

[David Weinrich <dw...@home.com>]

On Wed, 28 Feb 2001, Morgan Delagrange wrote:

...snipped here to prevent filling up your mailbox with duplicate stuff...

>
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
>
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
>
> 1) Different charters
>
> Avalon's charter is:
>
>   The Avalon project is an effort to create,
>   design, develop and maintain a common
>   framework for server applications written
>   using the Java language. This framework will
>   not be a standalone product, but will allow
>   existing and yet to be created server
>   applications to fit into a common platform
>   and to share code, design and human resources.
>
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.

I understand it this way too. A not-totally related point is, if it takes
more than a few of us more than a few days of digging to really nail down
exactly what Avalon is, would it be reasonable to expect a first time
visitor to Avalon to understand it as a place to get individual
components?

>
> The Library project is quite different.  It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function.  More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)
>
> 2) Different organization
>
> Our intention with Library is to make each component a
> microcosm within the Library subproject.  A component
> has its own documentation, including FAQ, quick start
> guide, etc.  It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs.  This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.
>
And along those lines, the components are inherently neutral in terms of
being tied to one of many different versions of the "one and only way to
do it". But I guess that is just restating what you say below :)

> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?
>
> Turbine seems like the wrong choice.  Where is the
> documentation for the dbPool?  Is it adequate on its
> own, or will the taglib implementer have to configure
> lots of unrelated Turbine functionality as well?  I'm
> also somewhat uncomfortable pointing people to the
> Turbine project, many of whose members are anti-JSP
> and therefore anti-Taglib.  The last thing I want is
> for users to be met with condescension when they ask
> the Turbine mailing list for help, which is quite
> possible in the current political climate.
>
> Struts is probably more appropriate, but it's still
> one big JAR.  It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental.  It's a good
> implementation, but it's a little buried within the
> website.  In face it's not obvious to the uninitiated
> that their database pool even exists.
>
> So, I guess I could go to Avalon and ask them to
> implement a database pool, but I'm still faced with
> the same old questions.  How much of the database pool
> is going to be tied up in the Avalon framework?  How
> self-contained will the documentation and
> implementation be?  Who's going to write it?
>
> This is a specific example, which to me underscores
> the need for a framework-independent repository of
> mini-subprojects.
>
> 3) Different scope
>
> The Library project should specifically steer clear of
> developing grand frameworks.  That kind of development
> is much more appropriate for full-blown subprojects
> like Turbine, Struts, and Avalon.
>
> 4) Convergent goals
>
> When possible, other frameworks can plug Library
> components into their framework.  The Library project
> is not intended to be a replacement to Avalong, Struts
> or Turbine.  Rather it's a place for convergence,
> where they can farm out self-contained components and
> focus on the means for tying them together.
>
> In some cases, a component may be able to be
> completely external to the project.  For example,
> perhaps Struts does not really need to reference
> directly the database pooling code, if it can still
> grab connections from a JNDI DataSource or a pooling
> Driver.  Then we've really reached Nirvana, components
> with interfaces so clean that we can literatlly swap
> implementations in and out at will.
>

+1 for nirvana!

> As long as we focus exclusively on frameworks, I think
> it will be very difficult to reach these ends.
>
> - Morgan
>
> =====
> Morgan Delagrange
> Britannica.com
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>

Re: Riffing again on another tangent

[David Weinrich <dw...@home.com>]

On Wed, 28 Feb 2001, Morgan Delagrange wrote:

...snipped here to prevent filling up your mailbox with duplicate stuff...

>
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
>
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
>
> 1) Different charters
>
> Avalon's charter is:
>
>   The Avalon project is an effort to create,
>   design, develop and maintain a common
>   framework for server applications written
>   using the Java language. This framework will
>   not be a standalone product, but will allow
>   existing and yet to be created server
>   applications to fit into a common platform
>   and to share code, design and human resources.
>
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.

I understand it this way too. A not-totally related point is, if it takes
more than a few of us more than a few days of digging to really nail down
exactly what Avalon is, would it be reasonable to expect a first time
visitor to Avalon to understand it as a place to get individual
components?

>
> The Library project is quite different.  It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function.  More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)
>
> 2) Different organization
>
> Our intention with Library is to make each component a
> microcosm within the Library subproject.  A component
> has its own documentation, including FAQ, quick start
> guide, etc.  It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs.  This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.
>
And along those lines, the components are inherently neutral in terms of
being tied to one of many different versions of the "one and only way to
do it". But I guess that is just restating what you say below :)

> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects.  I
> have a little JDBC tag library that we're about to
> release in Taglibs.  However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool.  The question is, whose?
>
> Turbine seems like the wrong choice.  Where is the
> documentation for the dbPool?  Is it adequate on its
> own, or will the taglib implementer have to configure
> lots of unrelated Turbine functionality as well?  I'm
> also somewhat uncomfortable pointing people to the
> Turbine project, many of whose members are anti-JSP
> and therefore anti-Taglib.  The last thing I want is
> for users to be met with condescension when they ask
> the Turbine mailing list for help, which is quite
> possible in the current political climate.
>
> Struts is probably more appropriate, but it's still
> one big JAR.  It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental.  It's a good
> implementation, but it's a little buried within the
> website.  In face it's not obvious to the uninitiated
> that their database pool even exists.
>
> So, I guess I could go to Avalon and ask them to
> implement a database pool, but I'm still faced with
> the same old questions.  How much of the database pool
> is going to be tied up in the Avalon framework?  How
> self-contained will the documentation and
> implementation be?  Who's going to write it?
>
> This is a specific example, which to me underscores
> the need for a framework-independent repository of
> mini-subprojects.
>
> 3) Different scope
>
> The Library project should specifically steer clear of
> developing grand frameworks.  That kind of development
> is much more appropriate for full-blown subprojects
> like Turbine, Struts, and Avalon.
>
> 4) Convergent goals
>
> When possible, other frameworks can plug Library
> components into their framework.  The Library project
> is not intended to be a replacement to Avalong, Struts
> or Turbine.  Rather it's a place for convergence,
> where they can farm out self-contained components and
> focus on the means for tying them together.
>
> In some cases, a component may be able to be
> completely external to the project.  For example,
> perhaps Struts does not really need to reference
> directly the database pooling code, if it can still
> grab connections from a JNDI DataSource or a pooling
> Driver.  Then we've really reached Nirvana, components
> with interfaces so clean that we can literatlly swap
> implementations in and out at will.
>

+1 for nirvana!

> As long as we focus exclusively on frameworks, I think
> it will be very difficult to reach these ends.
>
> - Morgan
>
> =====
> Morgan Delagrange
> Britannica.com
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>

Re: Riffing again on another tangent

[Morgan Delagrange <md...@yahoo.com>]

--- Sam Ruby <ru...@us.ibm.com> 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.

Hmm, it would be a damn shame to shoot down the
library project after making so much progress.

Here's my analysis of Avalon vs. Library, with a
little Turbine and Struts sprinkled in for good
measure.

1) Different charters

Avalon's charter is:

  The Avalon project is an effort to create, 
  design, develop and maintain a common 
  framework for server applications written 
  using the Java language. This framework will 
  not be a standalone product, but will allow 
  existing and yet to be created server 
  applications to fit into a common platform 
  and to share code, design and human resources. 

Note that Avalon is a _framework_ for servers, which
is clear from the API's many interfaces for request,
responses, pools, properties, etc.  

The Library project is quite different.  It's goal is
to create components, as self-contained as possible,
that perform (generally speaking) a single useful
function.  More specifically, one can implement
Library components _outside_ of the Avalon framework. 
(Turbine is a better example of a project where it is
necessary to implement the framework to make use of
the database pools, etc.)

2) Different organization

Our intention with Library is to make each component a
microcosm within the Library subproject.  A component
has its own documentation, including FAQ, quick start
guide, etc.  It's available as a seperate JAR and has
an explicit list of required/optional dependencies on
other JARs.  This should make sharing much easier,
since it will provide a grab-bag of functionality that
can be used without becoming tied to a framework.

Here's a specific example of the dilemna caused by
wrapping all our functionality in big projects.  I
have a little JDBC tag library that we're about to
release in Taglibs.  However, it's ridiculous for me
to implement my own database pooling for the tag,
because that's way out of scope for the project. 
Therefore, I'd like to point to somebody else's
database pool.  The question is, whose?  

Turbine seems like the wrong choice.  Where is the
documentation for the dbPool?  Is it adequate on its
own, or will the taglib implementer have to configure
lots of unrelated Turbine functionality as well?  I'm
also somewhat uncomfortable pointing people to the
Turbine project, many of whose members are anti-JSP
and therefore anti-Taglib.  The last thing I want is
for users to be met with condescension when they ask
the Turbine mailing list for help, which is quite
possible in the current political climate.

Struts is probably more appropriate, but it's still
one big JAR.  It's also a "framework for building web
applications" where the inclusion of a database pool
seems, frankly, incidental.  It's a good
implementation, but it's a little buried within the
website.  In face it's not obvious to the uninitiated
that their database pool even exists.

So, I guess I could go to Avalon and ask them to
implement a database pool, but I'm still faced with
the same old questions.  How much of the database pool
is going to be tied up in the Avalon framework?  How
self-contained will the documentation and
implementation be?  Who's going to write it?

This is a specific example, which to me underscores
the need for a framework-independent repository of
mini-subprojects.

3) Different scope

The Library project should specifically steer clear of
developing grand frameworks.  That kind of development
is much more appropriate for full-blown subprojects
like Turbine, Struts, and Avalon.  

4) Convergent goals

When possible, other frameworks can plug Library
components into their framework.  The Library project
is not intended to be a replacement to Avalong, Struts
or Turbine.  Rather it's a place for convergence,
where they can farm out self-contained components and
focus on the means for tying them together.

In some cases, a component may be able to be
completely external to the project.  For example,
perhaps Struts does not really need to reference
directly the database pooling code, if it can still
grab connections from a JNDI DataSource or a pooling
Driver.  Then we've really reached Nirvana, components
with interfaces so clean that we can literatlly swap
implementations in and out at will.

As long as we focus exclusively on frameworks, I think
it will be very difficult to reach these ends.

- Morgan

=====
Morgan Delagrange
Britannica.com

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Re: Riffing again on another tangent

[Morgan Delagrange <md...@yahoo.com>]

--- Sam Ruby <ru...@us.ibm.com> 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.

Hmm, it would be a damn shame to shoot down the
library project after making so much progress.

Here's my analysis of Avalon vs. Library, with a
little Turbine and Struts sprinkled in for good
measure.

1) Different charters

Avalon's charter is:

  The Avalon project is an effort to create, 
  design, develop and maintain a common 
  framework for server applications written 
  using the Java language. This framework will 
  not be a standalone product, but will allow 
  existing and yet to be created server 
  applications to fit into a common platform 
  and to share code, design and human resources. 

Note that Avalon is a _framework_ for servers, which
is clear from the API's many interfaces for request,
responses, pools, properties, etc.  

The Library project is quite different.  It's goal is
to create components, as self-contained as possible,
that perform (generally speaking) a single useful
function.  More specifically, one can implement
Library components _outside_ of the Avalon framework. 
(Turbine is a better example of a project where it is
necessary to implement the framework to make use of
the database pools, etc.)

2) Different organization

Our intention with Library is to make each component a
microcosm within the Library subproject.  A component
has its own documentation, including FAQ, quick start
guide, etc.  It's available as a seperate JAR and has
an explicit list of required/optional dependencies on
other JARs.  This should make sharing much easier,
since it will provide a grab-bag of functionality that
can be used without becoming tied to a framework.

Here's a specific example of the dilemna caused by
wrapping all our functionality in big projects.  I
have a little JDBC tag library that we're about to
release in Taglibs.  However, it's ridiculous for me
to implement my own database pooling for the tag,
because that's way out of scope for the project. 
Therefore, I'd like to point to somebody else's
database pool.  The question is, whose?  

Turbine seems like the wrong choice.  Where is the
documentation for the dbPool?  Is it adequate on its
own, or will the taglib implementer have to configure
lots of unrelated Turbine functionality as well?  I'm
also somewhat uncomfortable pointing people to the
Turbine project, many of whose members are anti-JSP
and therefore anti-Taglib.  The last thing I want is
for users to be met with condescension when they ask
the Turbine mailing list for help, which is quite
possible in the current political climate.

Struts is probably more appropriate, but it's still
one big JAR.  It's also a "framework for building web
applications" where the inclusion of a database pool
seems, frankly, incidental.  It's a good
implementation, but it's a little buried within the
website.  In face it's not obvious to the uninitiated
that their database pool even exists.

So, I guess I could go to Avalon and ask them to
implement a database pool, but I'm still faced with
the same old questions.  How much of the database pool
is going to be tied up in the Avalon framework?  How
self-contained will the documentation and
implementation be?  Who's going to write it?

This is a specific example, which to me underscores
the need for a framework-independent repository of
mini-subprojects.

3) Different scope

The Library project should specifically steer clear of
developing grand frameworks.  That kind of development
is much more appropriate for full-blown subprojects
like Turbine, Struts, and Avalon.  

4) Convergent goals

When possible, other frameworks can plug Library
components into their framework.  The Library project
is not intended to be a replacement to Avalong, Struts
or Turbine.  Rather it's a place for convergence,
where they can farm out self-contained components and
focus on the means for tying them together.

In some cases, a component may be able to be
completely external to the project.  For example,
perhaps Struts does not really need to reference
directly the database pooling code, if it can still
grab connections from a JNDI DataSource or a pooling
Driver.  Then we've really reached Nirvana, components
with interfaces so clean that we can literatlly swap
implementations in and out at will.

As long as we focus exclusively on frameworks, I think
it will be very difficult to reach these ends.

- Morgan

=====
Morgan Delagrange
Britannica.com

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/