Paul Hammant wrote:
> Folks,
>
> There appears to be a little discord present in the avalon-dev list,
> and hence the Avalon Developer community. I'd like to propose that we
> seek to achieve multiple things ...
>
> 1) calm things down.
+1
The biggest contributing factory will be some rational discussion about
changes.
>
>
> 2) arbitrate between opposing factions
Here is a summary of my view of the issues:
1. Cornerstone
Conerstone is an Avalon poject that includes several
utility components. Several of these components are
used within the scope of external projects in the
context of service and component managers. While
attempting to use the cornerstone jar from the CVS
with James, I encounter class cast exception when
a ComponentManager was attempring to return a
cornerstone component as a Component instance.
I corrected this issue by reincluding the Component
interface. Pete has -1'ed the revision without
supplying an explination.
Cornerstone remains broken.
2. Cornerstone components have for a long time been
considered as a set of Phoenix blocks. With the
introduction of Merlin, we have the potential for
Cornerstone blocks to be used not only within the
scope of Phoenix, but across any other container that
supports the Avalon Meta Model DTD.
To enable containers other than Phoenix to use the
Cornerstone components, I added a set of resources
(equivalent to the .xinfo named .xtype to avoid
conflict with Phoenix).
A modification to the build file was made to include
the resources into the jar file. This modification
was -1'ed by Pete on the grounds of introducing
meta-info dependecies and Pete's desire to reserve
".xprofile" for Phoenix - both arguments have addressed,
showing (a) no implied meta-info - its a DTD question,
and (b) a description of how one .something file can be
used with different DTD. No response, objection or
disagreement was raised by Pete to any of these
messages.
Some questions come out of this:
1. Are Cornerstone components intended to be exclusive to
Phoenix or are they intended to be re-usable across
Avalon containers?
2. Should Cornerstone componets implement Component
interface or not (in particular taking into account there
existing usage with ComponentManager based systems in the
field)?
3. Should resolution of the DTD question be solved first
(taking into account recent updates to the Type DTD to
fully support the Phoenix blockinfo requirements)?
3. Recent modifications were made to the way Phoenix creates a
BlockInfo class. These modifications simply checked the root
element type and build the Phoenix BlockInfo accordingly.
These changes have been -1'ed by Pete without justification.
My only rationale explination I can see is that Pete is
simply attempting to oppose anything that would facilitate
component reuse outside of Phoenix. I believe that this an
attitude will simply result in the death of Phoenix. I don't
see that as too great a problem as the Merlin/Fortress work
is in many areas significantly ahead of Phoenix. However,
Pete's continued opposition to an open-container world is
damaging overall Avalon credibility and remains a very real
concern.
>
> 3) consider what is best for individual sub-projects of Avalon
> constantly.
I recently posted an email to the James list in feedback to critisism
about Avalon. That email request more specifics - things that could be
dealt with. I received a lot of off-list replies. Within these the
most significant issue was Avalon version management. I was a little
suprised until I realized that everyone out-there looks at "Avalon" as:
* Framework
* Excalibur everything
* Cornerstone components
* Phoenix
* and all of the Avalon Apps content
When something is a component inside cornerstone breaks, the message
"Avalon is broken again". When Phoenix doesn't supply the row column
and source of a configuration exception - its "Avalon doesn't do
this...". Bottom line - they are right - looking at the Avalon
big-picture there are lots of inconsitencies. Lets's not focus on what
best for avalon sub-projects, but instead, lets focus on what's best for
the Avalon user community. Let's eliminate the artificial segregation
we have between projects and get on with the job of delivering and
properly maintaining great component solutions.
>
> 4) define whether we should be voting in advance or in arrears
> of significant contributions to common projects (nobody gives
> stuff what I do to apps/db/** right?)
I think comes down to one of the issues raised by the James people.
Aside for the 4 CVS division (which is a real source of confusion), we
don't have a good framework fo seperating early development from
released projects.
One suggestion from a James committer was to follow the commons appraoch:
* Merge Avalon Framework / Excalibur / Phoenix into a single CVS
* composition of the cvs based on
- released projects
- Framework
- Excalibur released utilities
- Phoenix
- Individual cornerstone released components
- a scratchpad project (trial/experimentation/pre-release)
- Excalibur pre-release utilities
- Merlin
- Fortress
- Some of the cornerstone components
- a playground project
- Tweety
- demonstrations
Escalation of a scratchpad project to an Avalon project should be
something properly managed and the notion of ownership should move from
the "initiator" to the "community". This would encourage segregation
between release verus development projects. For example I would not be
able to able to add content to Phoneix that depended on a scratch
project. User's would see one site - a consitent set of documentation
and with release status (Alpha, Beta, Final, etc.). Properly packaged
components and utilities with version management not just on the
framework, but on all of the released Avalon content.
>
> 5) aim to be all lovey-dovey from a point of time none to distant in
> the future.
I skip on this one - lovey-dovey isn't going to solve the problem.
Some good, detailed explinations from Pete would go a long way towards
resolving things.
Cheers, Steve.
>
> I'd like to vote +1 for each of the above to kick things off.
>
> I'd also like to add something from a personal agenda:
>
> 6) each and every committer should consider xdocs source to be
> temporarily
> more important than java source and got on with some additions.
> Even if
> compiling it is strangely beyond them, I will consent to fix
> compilation
> issues
>
> +1 for that too.
>
> Non committers could voice their solidarity to the process by with a
> single comment persuading us go with peacemaking if they believe it is
> best.
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
