Peter Donald wrote:
> So what I would be interested in doing would be to ask the PMC to allow us
> to create a new CVS (jakarta-avalon-catalog or something). This would be
> the place to burn through all the ideas and see where it leads. At the
> point where the project could stand on it's own two feet I would like to
> see it spun off into it's own project and avalons charter amended to
> exclude the new catalog library.
I think most of us are still unclear on what Avalon is now becoming.
It's been mentioned that the text on the Web site is obsolete,
and that if the library offered "multiple implementations and
[encouraged] javabeans style components", it would be different
enough from Avalon to standalone (see below).
More importantly, the key consensus-making points for this proposal are
+ Each package is treated as an independent deliverable.
+ Feature overlap and alternate implementations both between and within
packages is expected.
+ Any Jakarta committer can open a CVS branch for a codebase they are
developing.
+ The library's catalog will index other packages relevant to Jakarta
products.
If we lose any of these points, I believe we will also lose our
consensus.
In my own mind, I visualize the library as
(1) A catalog of reusable components available from any and all Jakarta
subprojects, including user contributions.
(2) A place where people can create and maintain production-quality
packages designed for reuse.
(3) A place where any Jakarta committer can bring (or create) new code
they want to share between products.
Is this compatible with Avalon?
-Ted.
Peter Donald (previously) wrote:
>
> Ted Husted wrote:
>
> >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.
