Leo Sutic wrote:
>
>>From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>>
>>Avalon Committers : I'd like a vote of confidence please.
>>
>
>+100 for trying, mate.
>
>+1 for keeping on trying, but
>
>+0 for your chances of success.
>
>Mediation is only useful if the two sides want to get along. So far
>it seems like Peter and Stephen are fine with making any compromise
>and that they are happy to include any Merlin/Phoenix feature - as
>long as the end result is *exactly* like they intended it all along.
>
Leo:
Let me point out to you a two or three facts of life:
1. forking occured due to an impossible situation
2. since the fork, the work on excalibur/meta has evolved to
include:
- Leo's (the other Leo) suggestions concerning API improvement
- Berin and Pete's position on terminology re stage/phase
- General concensus on terminology appliced to classes
- Fortress requirements on of lifecycle extension (subsequently
incorporated in Merlin)
- changes to the API based on trials focussing on Coocoon
requirements introduced by Nicola
- numerouse documentation enhancements and improvements
3. lots of trials across different applications
- James, raises issue with Cornerstone and Phoneix on
component portability (resolved)
- EOB, raised isssues on component protability (pending)
- Cornerstone, raises issue on component portability
(unresolved - Pete's -1s)
- OSM commercal apps - raised issues concerning component
protability (resolved), massive simplification in
deployment model is in progress and resulting in delivery
of remotetly accessible containers
- actions between Fortress and Merlin leading to establishment
of a common lifestyle managemnt solution based on collaboration
and contributions from Berin and Marcus
The excalibur/meta package is not what I intended it to me. In fact I
never intended excalibur/meta to even exist. I was necessity brought
about by Pete's abuse of -1 semantics. With the establishment of
excalibur/meta as a stucture enabling actions to proceed, the package
hase evolved substantially based on feedback and constructive input from
this forum.
I have to disagree with you.
This isn't what I indended - it's better - a lot better!
>
>
>The man with the plan, and Heaven help anything that the straight line
>from either of them to their goal intersects. I don't mind that - with
>an exception I'll get back to below - design by Guru is a remarkably
>fast way of getting good stuff done fast fast fast, because you don't
>have to spend time explaining the vision or plan and align everyone.
>I'm not the slightest surprised at Peter's two-week attribute-driven
>blitzkrieg - if anything it is that the business logic wasn't finished
>after 2w, but I guess management takes time.
>
>I'm not sure that the Phoenix way is the way to go - too static. I'm not
>sure the Merlin way is the way to go - too much magic.
>
Read the documentation - no magic - just practical solutions to
requirements.
http://jakarta.apache.org/avalon/merlin
http://jakarta.apache.org/avalon/meta
http://jakarta.apache.org/avalon/container
>All I want is no changes to Framework. As long as Avalon/Framework
>has all contracts and all classes needed to write a container or a
>component, I'm fine.
>
+1
Cheers, Steve.
--
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]>
