Re: Plea for Clarity

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

There are a number of differences between SourceForge and Apache.  The
tooling aspects is just one difference.  The community models are also
quite different.  I personally feel the latter is more important.

I've been holding back as I really want to push this decision down, but my
preference is that

1) The scope starts small.  Once the community aspects of getting disparate
   projects (e.g., Struts and Turbine) to share common code are resolved,
   determine an appropriate rate of growth.

2) The ability of "consumers" to trust the stability of the code base takes
   precedence over establishing diversity.

3) Jakarta committers are considered "pre-approved", but are only
   considered for inclusion if they express a commitment to maintaining a
   portion of the code base.

4) The scope is aligned with, and complements, Avalon's scope.

- Sam Ruby

Re: Plea for Clarity

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

At 05:22  18/2/01 -0500, Ted Husted wrote:
>Peter Donald wrote:
>> I am curious why you sought this path. If you wanted developers vetting a
>> library project - then we already have one of those projects at Apache
>> (namely Avalon). Avalons charter is to act as a repository of well designed
>> general utilities for server products. (its scope widened to any component
>> based products later).
>
>Sam Ruby wrote:
>> 
>> 4) The scope is aligned with, and complements, Avalon's scope.
>
>
>I haven't been paying a lot of attention to Avalon, since I had been
>working from the outdated description on the Web site. I'm mainly
>interested in building applications from server software, rather than
>building the server software itself.
>
>Would someone please 
>
>(1) State Avalon's current charter for the record.

It's original charter was

* a repository of well designed components for building server-side products

Overtime the patterns used within Avalon spawned a kernel/core-services bit
that can be used to build servers (ala mail/servlet/whatever) however the
core can still be used for things like servlet development (see Coccon for
an example of this). Some of the patterns are general enough that they can
be used in general component based apps (ie I use it in
graphics/gui/processing and network apps).

>(2) Contrast and compare how this proposed project might be aligned with
>and complement Avalon's new scope. 

Well I hope eventually that Avalon will become a repository of established
patterns/framework. All utility code would be moved to library project, all
kernel/services code moved to another project.

I see the library as a place for "unvetted" code that can possibly have
multiple implementations. If we start vetting code then library will just
be Avalon2 in practive and will fall down same path. 

The problem I see that as components get more complex (they dbpool example
for instance) you will see that there is a direct trade off between
inter-component and intra-component duplicity. 

Example: inter component duplicity will mean each component has a different
way of configuring itself while intra component duplicity would mean that
all components use a unified configuring system.

No person in their write mind would adopt a situation where you have 5
different config methods/files for 5 different components in one
application. Consequently this will either use copy-paste reuse or evolve
towards a unified configuring system - ie Exactly where Avalon is at ;)

So by unvetting things and allowing multiple implementations and
encouraging javabeans style components I believe we can avoid this and
build a project different enough from Avalon that it could stand on it's own.

>(3) Tell me where the CVS is called; it's not listed on the main Jakarta
>index, and "jakarta-avalon" didn't seem to work. I tried the
>distribution, but it didn't seem to be more current than the Web site.

It is still on java.apache.org - check out the link at
http://java.apache.org/main/cvs.html

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: Plea for Clarity

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

At 05:22  18/2/01 -0500, Ted Husted wrote:
>Peter Donald wrote:
>> I am curious why you sought this path. If you wanted developers vetting a
>> library project - then we already have one of those projects at Apache
>> (namely Avalon). Avalons charter is to act as a repository of well designed
>> general utilities for server products. (its scope widened to any component
>> based products later).
>
>Sam Ruby wrote:
>> 
>> 4) The scope is aligned with, and complements, Avalon's scope.
>
>
>I haven't been paying a lot of attention to Avalon, since I had been
>working from the outdated description on the Web site. I'm mainly
>interested in building applications from server software, rather than
>building the server software itself.
>
>Would someone please 
>
>(1) State Avalon's current charter for the record.

It's original charter was

* a repository of well designed components for building server-side products

Overtime the patterns used within Avalon spawned a kernel/core-services bit
that can be used to build servers (ala mail/servlet/whatever) however the
core can still be used for things like servlet development (see Coccon for
an example of this). Some of the patterns are general enough that they can
be used in general component based apps (ie I use it in
graphics/gui/processing and network apps).

>(2) Contrast and compare how this proposed project might be aligned with
>and complement Avalon's new scope. 

Well I hope eventually that Avalon will become a repository of established
patterns/framework. All utility code would be moved to library project, all
kernel/services code moved to another project.

I see the library as a place for "unvetted" code that can possibly have
multiple implementations. If we start vetting code then library will just
be Avalon2 in practive and will fall down same path. 

The problem I see that as components get more complex (they dbpool example
for instance) you will see that there is a direct trade off between
inter-component and intra-component duplicity. 

Example: inter component duplicity will mean each component has a different
way of configuring itself while intra component duplicity would mean that
all components use a unified configuring system.

No person in their write mind would adopt a situation where you have 5
different config methods/files for 5 different components in one
application. Consequently this will either use copy-paste reuse or evolve
towards a unified configuring system - ie Exactly where Avalon is at ;)

So by unvetting things and allowing multiple implementations and
encouraging javabeans style components I believe we can avoid this and
build a project different enough from Avalon that it could stand on it's own.

>(3) Tell me where the CVS is called; it's not listed on the main Jakarta
>index, and "jakarta-avalon" didn't seem to work. I tried the
>distribution, but it didn't seem to be more current than the Web site.

It is still on java.apache.org - check out the link at
http://java.apache.org/main/cvs.html

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: Plea for Clarity

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

Peter Donald wrote:
> I am curious why you sought this path. If you wanted developers vetting a
> library project - then we already have one of those projects at Apache
> (namely Avalon). Avalons charter is to act as a repository of well designed
> general utilities for server products. (its scope widened to any component
> based products later).

Sam Ruby wrote:
> 
> 4) The scope is aligned with, and complements, Avalon's scope.


I haven't been paying a lot of attention to Avalon, since I had been
working from the outdated description on the Web site. I'm mainly
interested in building applications from server software, rather than
building the server software itself.

Would someone please 

(1) State Avalon's current charter for the record.

(2) Contrast and compare how this proposed project might be aligned with
and complement Avalon's new scope. 

(3) Tell me where the CVS is called; it's not listed on the main Jakarta
index, and "jakarta-avalon" didn't seem to work. I tried the
distribution, but it didn't seem to be more current than the Web site.

-T.

Re: Plea for Clarity

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

Peter Donald wrote:
> I am curious why you sought this path. If you wanted developers vetting a
> library project - then we already have one of those projects at Apache
> (namely Avalon). Avalons charter is to act as a repository of well designed
> general utilities for server products. (its scope widened to any component
> based products later).

Sam Ruby wrote:
> 
> 4) The scope is aligned with, and complements, Avalon's scope.


I haven't been paying a lot of attention to Avalon, since I had been
working from the outdated description on the Web site. I'm mainly
interested in building applications from server software, rather than
building the server software itself.

Would someone please 

(1) State Avalon's current charter for the record.

(2) Contrast and compare how this proposed project might be aligned with
and complement Avalon's new scope. 

(3) Tell me where the CVS is called; it's not listed on the main Jakarta
index, and "jakarta-avalon" didn't seem to work. I tried the
distribution, but it didn't seem to be more current than the Web site.

-T.