----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]>
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.
I dare to say : it will be easier :-) But I'm not sure it is the correct strategy.
Hey, I don't know, I'm just some guy saying that we should start from the
simplest thing and then - as necessity happens - going to complex
environment. Your strategy is to keep Meta as it is and add migrations tools
to others containers.
Correct.
What about other containers store information in their specific way instead of Meta package pushing his own way/format? Thats my point. No migration tool would be need now.
That's also my point. If this scenario where endorsed - we would have islands of components build for a particular container as opposed to components that are build for Avalon compliance. That's a scenario that am strongly opposed to.
This conclusion came from the fact I already tried to adapt Fortress to Meta few months ago Well, didn't happen :-\
As far as I understand - the only issue that needs to be addressed is the requirement that Fortress concerning a catalog of available components. If a catalog is generated and supplied to Fortress (using a Fortress specific build-time tool) then everything is available to Fortress relative to the current Avalon Meta package. It can read in the component type definitions, create and index of service providers, index extension providers, and use these indexes when resolving candidate components.
There are few aspects that could drive our direction: * Existing containers * Existing application * New containers
New containers could benefit from Meta package as it is. The problem exists in first two bullets. Answer my post pretending you're not Merlin developer, just someone with the big picture in hands and the background of the last week posts ;-)
Bottom line is this - if you are a component developer, it is desirable to minimize the container specific overhead.
Take for example the overhead that Merlin places on a developer:
a) if they want to package profiles - they need to write
a Merlin specific xprofile descriptor b) if the want to disable proxy handling - they need to
declare attributes in the meta-info descriptor that
is specific to the composition package c) if they want to deploy a component they have to write
a block directive that is specific to the composition
package d) if they want to change the personality of the container
they need to modify a merlin specific kernel descriptionLets take these one by one.
For case (a) - the packing of deployment directives with a component type .. well, Fortress uses a different meta-data model so Fortress users would need to do something different (and they current do - its called the roles file). At the end of the day would it not be better that this sort of information was declared in a standard format?. But to get to a standard meta-data model we need a standard meta-info model (i.e. the expression of a requirement comes before the expression of a solution).
Example (b) - the usage of container specific attributes - its an example that demonstrates the weakness of the current model - in particular, the current model does not expose the fact that an attribute represents a runtime requirement. So ... something on the agenda for implementation at the API and implementation level - standard attributes that relate to runtime policies.
Example (c) - container specific meta-data ... have you every had to deal with 160k Phoenix assembly file and wonder how your going to migrate to another container? As we evolve our art - the question of the component spec will fade in history because we will have resolved each and every gray area. Instead - we will be focusing on the overhead implied by container solutions. And here Avalon can set the container meta-data reference.
Example (d) - this is what is going to send Phoenix to its grave, put an end to Fortress, and give Merlin a such an identity crisis that for all practical purposes - Merlin will exist only in our dreams.
Now ... to get back to your point "I'm not a Merlin developer and I'm just someone impressed by last weeks traffic" ...
What I would do (as a container developer):
* write a tool the supports the translation of my user base to
the standard framework * identify shortcomings with the implementation, investigate
discussions on how the implementation could evolve to better
meet additional/supplementary "semantic requirements",
contribute to the package development and evolution * leverage the "standard" Avalon platform to the maximum
extent possibleWhat I would do (as a component developer):
* avoid anything that is container specific
* post comments to [EMAIL PROTECTED] asking why anyone believes
that meta-info is not absolutely essential to the definition
of a binary-portable common component model * ask the dev community why we haven't resolve a common
meta-data model * ask the dev community what the road map is for the single
container architecture - runtime component contract (done)
- meta-info (done)
- meta-data
- meta model API
- container SPIBut how do we get there? We get there by abstracting out a standard framework.
* meta-info (component type requirements) - DONE!!! * meta-data (assembly directives to a container) - COMING!!!
Avalon Meta only handles the meta-info side of the equation - i.e. the simple stuff. But potential exists to migrate Merlin and Fortress meta-data solutions to a standard model. Do that and your starting to see a situation where Merlin and Fortress are simply implementations of a Avalon component management architecture.
Wow - achieve this and nobody will care about which container - Merlin will be dead, Fortress will be dead, we will just have the Avalon platform, a reference implementation, and a bunch of pluggable facilities.
Cheers, Steve.
regards, hammett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | 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]
