----- Original Message ----- From: "Leo Simons" <[EMAIL PROTECTED]>
<...>
It may be not a standard yet, but lets be practical: how to make it standard?
My suggestion: - The current builder package (in impl) should move to Merlin.
The builder package contains the implementation of the readers of serialized and XML type and service descriptors. It is used by the tools package and plugin package as part of the process of translating legacy content (such as Phoenix metainfo) to a standard form.
Rather than move the builder content (and by inference - tools and plugin) to Merlin, it would make more sense to add a migration tool to the Fortress package to ensure that meta-info is represented in a common way.
- Fortress should implement its own Builder based on what is actualling doing for service/components.
A Fortress Migration tool could read in Fortress specific content and write this out to an Avalon Meta format. The Fortress container could then either read this content in using the existing builder package, or write its own reader using the "standard" format for persistent meta-info.
- Any other container should follow the same path.
The imperative aspect is the "standard" specification of a component descriptor and its packaging model such that any Avalon compliance component can be deployed within any container simply because we have a single "standard-binary-contract".
The current Builder implementation is Merlin specific - and I agree should
not be considered an Avalon standard.
I agree that there are aspects concerning serialized forms that should not be considered as part of the Avalon standard persistent form (but the serialized forms can be used improve efficiency - for example, to cache Type descriptors). However - I see nothing Merlin specific about this or any other characteristics of the builder implementation - but I also think its kind of a null-issue. What exists provides a default implementation but that does not stop anyone from writing alternative implementations.
Even more important, I think that there are lots of things we can do to make the builder implementation more extensible - but I think that such development should be maintained within the meta package.
Cheers, Stephen.
However the Meta package describes the flesh and bone of an Avalon component/services and related facilities. So its a good idea to use it an standard (I port it to .Net right this time and notice how its supress strategies I already made in my first container implementation)
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
