Paul Hammant wrote:
> Stephen,
>
>>> 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.
>
>
> Well that is probably nearer my fault. I upgraded in Phoenix inside
> JAMES CVS. I should have put back the previous cornerstone.jar that
> they were using as it was Component using. We have known for months
> that JAMES has a problem with the removal of Component. The problem
> is one of backwards-compatability given that maillets are handed a
> Context which has getComponentManager() method (v eryun IoC). I'm
> taking this on the chin not Peter. The whole of the Avalon community
> mulled how to get rid of Component months ago and I, as an un-official
> JAMES laison, failed to reslove the remaining issue.
Sorry - this doesn't explain Pete's actions of deleting bug fixes or his
inability to respond to issued raised. Pete is preventing the solution -
that's an issue. Please, if you feel responsible for this then make the
changes and deal with Pete's -1's. I'll be more than happy!
>
>> 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.
>
>
> It appears that the need for .xprofile and .xtype is the issue.
> Laymen, such as myself migh ask 'why is not .xinfo not sufficient'?
Phoenix reads in an xinfo file and does not take into consideration the
DTD. It assumes everyting is the blockinfo DTD. The recent update to
Phoenix that Pete -1'ed updated Phoenix so that a BlockInfo could be
created from both a blockinfo DTD and a Type DTD. That would have
enabled the elimination of the .xtype resources. However, Pete's
deletion of these updates (with no justification or comment) means that
they will have to be re-asserted into the CVS (Pete's veto remains
invalid).
The necessity for the .xtype and .xprofile comes down to the fact that
the blockinfo is a primitate descriptor relative to the Type DTD.
Merlin can use much more information than that available in blockinfo
and in some cases requires additional information in order to work
around componets that include BlockContext references. In these
situations, Merlin needs a type declaration that contains the statement
of the contextualization phase criteria. In the profile.xml, a bundled
defintion is provided that Merlin can use to automatically create the
BlockInfo instance based on profile directives.
>
>
>> 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?
>
>
> Multiple containers is what I have been telling people for years.
> Does each container have its own .x* files? Refer my point above.
> The conflict area is the xml manifests the developer (rather than the
> assembler) makes.
Multiple contains can either:
a) use a common DTD (the desitable scenario)
b) use seperate DTDs (a workable scenario assuming collaboration)
c) use seperate extensions (necessary to achieve a working solution
relative the the current players) but breaks oppotunity for re-use
of components across containers.
The situation isn't that difficult to understand:
1. a container reads a .xinfo into a configuration instance
(and can restrict itself to specific DTDs)
2. a container implementation checks the top level element to see
if it is something it can suport
3. a continer generates its own internal model based on the
configration as the source
>
>> 2. Should Cornerstone componets implement Component
>> interface or not (in particular taking into account there
>> existing usage with ComponentManager based systems in the
>> field)?
>
>
> I'd hope we can find a way where Component is finally shoved into
> obscurity. Part of this involves me publishing a new JAMES Maillet
> API (born from my work on Jesktop and EOB).
>
>> 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)?
>
>
> One would hope there is a healthy discussion that leads us to a DTD
> resolution, and then something that can be committed.
Me too!
The Type DTD has evolved such that is COMLETELY address all of the
requirements expressed by the Fortress, Merlin and Phoenix usage
scanarios. The same canot be said of any other meta-info DTD.
>
>> 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.
>
>
> Perhaps we could seek a reason for this.
So far Pete has chosen to ignore this question.
I would really like to hear his reational as well - however, I suspect
he simply will not answer you request.
>
>> 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.
>
>
> My hope is that Peter is only making sure that the component contract
> changes are well thought out and carefully planned. I think Peter has
> no formal objections to other containers that can mount either a)
> existing blocks or b) entire SAR files. With respect to a) I am
> guessing Peter believes the contract with the .xinfo files (and
> .mxinfo for mgmt) is good enough. I am guessing that Peter has no
> opposition to those other containers not using assembly.xml and
> config.xml. I'm putting words in Peter's mouth here (my
> second-guessing gland quite often goes into overdrive), so perhaps
> Peter can clarify where the differences for alternate container should
> be apparent.
Pete has replied to this - however - he failed to address the question
you raised - "clarification where the differences for alternate
containers should be apparent". He has addressed his own agenda -
containerkit.
Let's not fall into the false impression that this repsent the community.
>
>
>>> 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
>
>
> It has taken me some time to publish the fact that there are
> sub-projects to Avalon. Some of the JAMESers had a principal
> objection to Phoenix but expressed it as "I hate Avalon". I felt my
> suggestion to think of things differntly would help our cause (Avalon
> is a project not a product).
With all of the "flack" email I received from James people - I'm
progressively moving towards thier point of view. Looking at Avalon
"the brand" there are big holes in out story due to our artifical
fragmentation. It doesn't matter is James people are right or wrong -
it matters that they represent an import part of our user community -
just as Cocoon does. These user's matter - there opions are the reality
of "what is Avalon".
>
>> 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
>
>
> We un merged some time ago.
I know,.
In hindsight - was it a good move?
I don't think so. It's led to fragmentation instead of dealing with
issues - ECM land verus Phoenix land, etc. Lack of relase managemnt,
lack of control, brand corruption.
>
>> * composition of the cvs based on
>> - released projects
>> - Framework
>> - Excalibur released utilities
>> - Phoenix
>> - Individual cornerstone released components
>
>
> +1 to Cornerstone splitup.
>
>> - a scratchpad project (trial/experimentation/pre-release)
>> - Excalibur pre-release utilities
>> - Merlin
>> - Fortress
>> - Some of the cornerstone components
>> - a playground project
>> - Tweety
>> - demonstrations
>
>
> My feeling is that if our documentation is good enough (" This is
> Alpha quality and not intended for production deployment "), then it
> is good enough. WRT Commons-Scratchpad. You'll remember I ran from
> there with AltRMI.
I remember comming to Avalon in the beginning and wondering what the
status of everything was. The documentation does not detail this. I've
emailed Pete and Berin and other at different times - asking what's the
status of this, what's the status of that. I've implemeted my own
solutions in some cases simply because I didn't have a good idea of what
the status was. The overarching structure and organization at the
Avalon top-level is missing.
>
>> 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.
>
>
> That is a good point. It would mean we lose some external comps, like
> MX4J which despite a 1.1 label is perhaps nearer a 0.99 release.
Yep.
>>> 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.
>
>
> Actually, I manages the perceptions of our user community. This is
> not a closed list. Every insulting, rude, sarcastic and derisory
> message on this list hampers the adpotion of any aspect of the Avalon
> project, and probably puts ammo in the guns of those actively dissing
> Avalon and its central patterns.
The notion of a community is central to the point you have raised. Go
back over the archives and look at the sustained opposition to community
based development by one individual. Solve that problem and you will
enable community development. Don't be misslead into thinking that
pretending that everything is ok will make everyting ok - it's not. What
is the cause of the type of messages you mentioned? It's the cause that
needs to be address - not the side-effects.
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]>
