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.
> 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'?
> 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.
> 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.
> 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.
> 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.
>> 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).
> 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.
> * 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.
> 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.
>> 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.
- Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
