Morning everyone:
(evening Pete :-))
Have been going through the "proposal" src tree in Avalon (org.apache.avalon
and org.apache.framework) with the objective of building up a similar
"specification/implementation" diagram to that shown below. After filling
up half a page with packages and dependencies I was left with the impression
that the proposal structure is substantially less structured that the
existing Avalon structure I outline below. So my assumption is that I'm
missing something fundamental here (perhaps I'm intellectually challenged) -
can anyone fill me in on the advantages of the proposed structure over and
above the existing structure, because the existing structure seems to be
reasonably clean in terms of dependence hierarchy)?
Cheers, Steve.
A little earlier today I wrote:
> Sent: Monday, 09 April, 2001 19:12
> To: Avalon Development
> Subject: RE: back to branding
>
>
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
