If you look at the "Avalon" big picture you can cut it into
"specification" and "implementation". The Specification
correspond to the Avalon stack shown below on the left. "Phoenix"
packaged as a RI along the lines Leo suggested makes lots of sense to
me - but the cornerstone server/demo composition needs a clean-up.
Repackage cornerstone demos as "Excalibur" and you start to see a
marketable structure.
Avalon
======
Specifciations Implementation
============== ==============
|------------------------| |------------------------|
| | | Excalibur |
| | |------------------------|
| avalon.atlantis | <-- | Phoenix |
|------------------------| | RI implementation |
| avalon.camalot | |(including Cornerstone |
|------------------------| | services) |
| avalon.component | |------------------------|
|------------------------|
| avalon.Configuration |
|------------------------|
| Avalon |
|------------------------|
I think that the introduction of something more stuctured will
facilitate a broad level of participation in the process, leading
to higher recognition and use.
Cheers, Steve.
> >More on sub-projects
> >====================
> >Generally, no two projects should depend on one another
> >(while cornerstone can depend on the framework spec, it
> >cannot depend on the impl as the impl depends on
> >cornerstone).
>
> unfortunately thats not really viable - unless we go through and create
> factories for everything. In some cases blocks require knowledge of
> implementation because they need to instantiate and manage
> context/CM/configuration objects. (ie see James block in James poject).
>
> >
> >Ideal setup:
> >
> >1 - Avalon specification 'working group'
> >2 - Avalon components 'working group' which creates usable
> > chunks of code for use in implementations and applications
> > using Avalon, probably according to demands from 3.
> >3 - Avalon reference implementation (phoenix) 'working
> > group' which creates impls of versions of the
> > spec from 1 and components from 2.
> >
> > 3.1 - responsible for the bulk of the RI
> > 3.2 - responsible for the atlantis part of the RI
> > 3.x - perhaps more sub-groups for parts of the RI,
> > like the Logger stuff.
> >4 - Avalon documentation 'working group' in which all other
> > groups also participate.
> >5 - Avalon deliverables/support 'working group' which creates
> > distributions and other deliverables and helps people set
> > those up, and probably manage the website.
> >
> >1 depends only on java in general
> >2 depends on 3
> >3 depends on 1 and 2
> >4 has no real dependencies
> >5 depends on 1 through 4.
> >
> >Branding would be the concern for 5. There's no problem with
> >both an "Avalon" and a "Phoenix" (sub-)brand, me thinks.
> >Perhaps number 2 deserves a nice mythological sub-brand as
> >well...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
