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]
