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
* there is no fork of Merlin that I am aware of
* there isn't a fork of the proposed extension mechamism
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.
>Forks are not evil in and of themselves. The problem occurs when
>there is no communication between the original projects and the
>forked versions. Also, the fork needs to answer some need that
>cannot be answered in the prior version. Sometimes the need is
>purely political, but that does not mean that you can't learn from
>the original authors. One thing that is important with forks is
>that you should *never* remove the original author tags.
>
If you are aware of a case where an original author tag is missing -
please advise.
></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.
> 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
>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.
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.
Operational:
You need collaboration for something to be common - it needs to build
based on an open attribute to community ideas.
>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.
Cheers, Steve.
>
>Lastly, I would like to see the extensions added to ContainerKit and
>have them marked clearly that not all containers have to support
>extensions, but they have to notify the developer if it detects a
>component that requires extensions and the container does not support
>them. If ContainerKit has validation in it, then that notification can
>be handled by ContainerKit. Optionally, the container or ContainerKit
>can issue a warning that the component is using non-standard extensions
>if it does support extensions. Would that be satisfactory?
>
>
>"They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
>--
>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]>
