Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>Berin Loritsch wrote:
>>
>>
>>
>>>Before we go too far down the holy grail crusader mentalities, lets
>>>keep in mind that neither ContainerKit nor Merlin's Meta
>>>
>>>
>>Model (which
>>
>>
>>>is what it is) has been voted on or accepted as the standard.
>>>Therefore NEITHER deserve the moniker Avalon Meta Model.
>>>
>>>
>>That cannot
>>
>>
>>>be given until we have decided on a standard.
>>>
>>><rant>
>>>The problem with excalibur as it stands is that there are too many
>>>forks of functionally equivalent things. We have a fork of
>>>ContainerKit, a fork of Merlin, and a fork of the proposed
>>>
>>>
>>extension mechanism.
>>
>>
>>>
>>>
>>>
>>>
>>I don't think this is correct.
>>
>>* there is a fork of a part of containerkit dealing with meta-info
>>management and container independent meta management resources
>>
>>
>
>But a fork nonetheless
>
>
Yes - but lets please be clear about what was forked. The fork was on a
specific sub-set. Whan use use the term containerkit you are refering
to a lot of backage - a lot of content that has nothing to do with
container interoperability.
>
>>* there is no fork of Merlin that I am aware of
>>
>>
>
>A fork is something that started in one repository and for some
>reason is moved to another while the original code is still maintained
>separately. Therefore, in the purest sense Merlin 2 is a fork of
>Merlin 1.
>
Exception that Merlin 1.0 (which is still in use during Merlin 2.0
development) is not the code base for Merlin 2.0. Merlin 2.0 was
started on a clean sheet of paper. Merlin 2.0 represents an evolution
of the Merlin 1.0 concepts. Therefore, in the purest sense, Merlin 2 is
a fork of the Merlin 1.0 concept.
;-)
>>* there isn't a fork of the proposed extension mechamism
>>
>>
>
>Your version was a fork of the one in Fortress. You developed it
>independently without discussing with us why we made the decisions
>we did.
>
>
No, that's not actually correct.
The initial extension implemetation inside Merlin was written in a way
that look into account the meta-info and meta-data context present in
the Merlin Framework. Yes - there was extensive review of the Fortress
implemetation - but it wasn't a fork. The work from Marcus in Fortess
supplied the inspiration but the implementation focussed on resolving
how to achieve equivalent functionality in a meta driven environment.
When that excersice was completed - thare was discussion and exchange
between Marcus, yourself and myself concerning the development of a
common set of interfaces that would enable the different implemetation
approachs to be interopperable.
>
>
>>There are some actions to seperate the container indepednent
>>resources in the Merlin project concerning the proposed
>>lifecycle management and the meta info management into seperate
>>packages that are independent of the Merlin package. This is
>>not forking - this is just putting thing in place so that they
>>are more easily re-used by other projects.
>>
>>
>>
>>></rant>
>>>
>>>Now, as the table that was in another thread showed, the
>>>ContainerKit Meta Model and the Merlin 2 Meta Model are
>>>largely equivelant.
>>>
>>>
>>>
>>Sorry for being padantic - but there are massive differences.
>> The minor differences your referring to concern the meta-info
>>model (the type level stuff). Beyond that the containerkit
>>resources proved unworkable in a dynamic environment. Due to
>>a general refusal by the author of containerkit to address
>>needs outside of his own area a fork of a part of containerkit
>>was made - in order to leverage the usable content. The
>>Merlin Meta Model is something else - it includes the Merlin
>>container specific content - it is part of the Merlin project.
>>It leverages the container neutral meta-info layer.
>>
>>
>
>Then we need to address exactly how much of a system *should*
>be made dynamic. And forgive me for being pedantic, but shouldn't
>we have just one meta model? Merlin==Fortress==Phoenix?
>
Probably not.
Fist of all - lets look at what a meta-model contains.
* meta-info, descibing a type of component
* meta-data, describing profiles of deployment of a particular
component type
Getting in place a common meta-info layer for an Avalon component
is reasonably strait-forward. This has been the objective of the
work put into the excalib/meta package.
When you get into the meta-data layer you start to see very
significant differences between containers. For example, Phoenix
meta-data boils down to the descriptions of component associations
and component configuration declared in the assembly.xml and
config.xml files. In Merlin the meta-data is expressed under a XML
file that describes the kernel and a container hierachy, together
with explicit component declarations within a container declaration.
In effect the meta-data layer is where container inovation will occur
for the vast majority of cases.
>
>I dislike too much stuff happening behind the scenes so that I
>have no clue what is going on.
>
I don't know what you referring to here.
Certainly nothing in the Merlin 2, lifecycle work, or meta model
work has been behind the scenes.
>
>>>The major distinction is that Merlin has support for Stage and
>>>Extension meta info. I need some clarification on the Stage
>>>meta info--if it is referring to Stephen's first cut at
>>>forking the extension mechanism then it needs to die. If not,
>>>then I need to know what it is talking about.
>>>
>>>
>>>
>>This is all documented. Please refer to the following page
>>and the respective javadoc on the meta-info types under the
>>org.apache.excalibur.meta.info package.
>>http://home.osm.net/doc/merlin/extensions.html
>>
>>
>
>I'll look at the document, but can you just say 'Yes' or 'No' and
>then provide the link for further clarification? It'll make things
>quicker.
>
>
If the question wasn't loaded you would probably get a strait answer!
;-)
>
>
>
>>>Either way, it is important to note that *Extensions* are
>>>just that--*Extensions*. Therefore containers are not required
>>>to implement them.
>>>
>>>However, if they are implemented, they should be implemented in a
>>>consistent manner. I would be happy with a meta model that
>>>validates that the extension can be satisfied, and if the
>>>container does not support the extension/stages then it needs to
>>>fail-fast and tell the developer that they cannot use that
>>>component in the container. The documentation for extensions
>>>must be resilliantly clear that you cannot expect components
>>>that take advantage of extensions to work in absolutely
>>>every container.
>>>
>>>Generally speaking, if ContainerKit does not provide validation, I
>>>would like to see it do so. I would *really* like to see a
>>>merging of Merlin/ContainerKit meta info. If there are any
>>>blockers to that happening that are technical in nature (technical,
>>>not political) I would like to hear it.
>>>
>>>
>>>
>>Technical:
>>
>> ContainerKit meta-data model cannot be used in a context where you
>> dynamically create associations between type profiles. This is
>> brought about by the problem that the entire conterkit structures
>> are immutable. This prevents dynamic construction and the potential
>> for dynamic replacement.
>>
>>
>
>Would it be able to regenerate the meta-data model when we reload
>configurations?
>
Yes.
The model currently provides support for the dynamic binding of a
candidate service provider with a target consumer component. The
intention is to be able to re-bind serivces so that a container can be
dynamically reconfigured (for example, in an edditor within which an
assembler disable one compoenent - Merlin automatically establishes
alternative candidates and defaults, and the assemble can select
prefered solutions or run using default solutions).
>We can make ContainerKit allow dynamic reassignment.
>
>
There is absolutely no techical reason why not.
However, you may run into some operation difficulties along the way.
>> ContainerKit attempts to define too much about how a
>>container should
>> be implemeted, resulting in a very large redundancy of classes. The
>> only realistic approach to building a common container
>>utilities group
>> is the progressive defintion of areas of common concern, progressive
>> collaboration between parties with different solution, and from that
>> the establishment of sharable utilities.
>>
>>
>
>Could you give me an example where the ContainerKit model artificially
>constrains you?
>
* lifecycle tools proved insufficient when dealing with
configuration and context management
* kernel, lifecycle, processor, and verifier packages all use
the static meta-data model (you cannot use these resources
unless you accept the liimitations of the meta-data
implementation)
* imputable contructors prevent any possibility for extension
of base classes for dynamic applications
* assembly strategy is based on the Phoenix static assembly model
- it does not provide sufficient flexibility for the adative
approach used in Merlin to automate assembly activities and
will not support the partial modification of structures - in
Merlin the container represents someting reconfigurable - using
the containerkit approach you would be forced to rebuild the
entire hierachy, not just a single container
>>Operational:
>>
>> You need collaboration for something to be common - it
>>needs to build
>> based on an open attribute to community ideas.
>>
>>
>
>True. However, if the original author believes that something should be
>immutable, it is worth our time to find out why.
>
>
Franklly, I've spent so much time on this - the author in question has
shown a clear unwillingness to adapt to other requirements, or even
discuss these. Too many -1s, too many insults, too many justifications
such as the phrase"it's not going to happen". Its worth spending time
when the time spent is in a constructive dialog.
Cheers, Steve.
>
>
>>>Another thing that would be emensely helpful is a suite of test
>>>cases for both ContainerKit and Merlin that prove their compatibility
>>>and their claims. Merlin has absolutely no testcases which makes me
>>>nervous. I haven't looked at the ContainerKit code, but if it has
>>>the same problem it needs to be rectified.
>>>
>>>
>>>
>>Merlin does not include formal test-cases at this time. It
>>does include several demonstrations and is constantly validated
>>against a large number of components here on my machine. Please
>>feel free to jump in with test cases into the Merlin project - all
>>contributions will be highly appreciated. In the meantime, my
>>priorities are to make sure that Merlin is complete and well
>>documeted before launching into the test-case preparation.
>>
>>
>
>I've got other things to do. Formal testcases are very important,
>and part of the proper validation of components and other pieces.
>One of the things I have to do is add more formal testcases for
>Fortress.
>
>
>
--
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]>
