Leo Sutic wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
* moving out of core means death to the idea of reliable deployment across containers
I think your social observations are spot-on, and your technical assessment is correct. The absence of the tag in the avalon
namespace makes it optional, and thus people will ignore it.
The absence also makes it impossible to guarantee that a component
will run in any Avalon container.
Yes... that's the crux of the situation.
But I think your summary is way off.
It is not the death of cross-container deployment. We will get there. Is it the death of Fortress/Merlin-style extensions? Maybe.
Consider that Merlin will not discontinue the use of extensions semantics - in fact if anything it will embrace these semantics at increasing more sophisticated and interesting ways. This means that Merlin will continue on a path that is deferent from the rest of Avalon - just as Phoenix and ECM split in two directions. What is important to recognize is that today this is a hair-line fracture - we can choose to recognize and resolve that fracture or we can choose to ignore it. In my opinion - this little hair-line fracture will grow and we will see real divergence. It will mean that Merlin will focus on providing a solution platform - not for Avalon components - but for Merlin components. Why, because is users follow Merlin rules they will be safe and if users follow Avalon rules they do so at their own risk.
I don't think the current extension model should go into the
core, because I don't think it satisfies all needs.
I agree that excalibur-extension should not go into core. I do not agree that the notion of deplyment phase depedencies can be considered non-core.
Peter Donald explained some difficulties with it - mostly it didn't support interceptors, which I have tried, used and found very helpful since then.
Keep in mind that this is not about excalibur-lifecycle - its about the notion of deployment dependencies as peers to runtime dependencies.
* an absence of an extension mechanism in @avalon core makes the proposal technically invalid
I don't understand this.
All the proposal says is this:
Put the extension stuff into @lifecycle, not @avalon, because, well, we just don't know whether this type of extensions will be the final version.
In what way is the proposal invalid?
The subject is about a set of tags that describe the requirements a container has to fulfil for reliable and predictable component deployment. To achieve that we must either (a) provide a complete model, or (b) provide a model extension mechanism. One of the options described in the vote will only result in division and failure to achieve the objective. As such the vote calls for unification but presents a solution that will divide. Hopefully a majority of people will figure out that this vote is premature and that perhaps there are some important and unresolved issues to be addressed. If not, I guess its history repeating itself.
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
