> 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 > * 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. > * 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. > 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? I dislike too much stuff happening behind the scenes so that I have no clue what is going on. > > 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. > >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? We can make ContainerKit allow dynamic reassignment. > 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? > 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. > >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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
