Nicola Ken Barozzi wrote:
Stephen McConnell wrote, On 18/07/2003 9.42:
...
Bottom line is that I don't think we should try to have Merlin deprecating Fortress - instead I think we have Fortress deprecating things progressively relative to a standard containment architecture. The difference is that Fortress would continue to exist to handle the delta between what is established as standard, and what is specific to the ECM legacy.
...
Basically I envisage a future in which the internals of Merlin are changing, evolving and adapting as we move towards the "perfect" solution. I should point out that I think that *release* should not be interprited as an *we-have-to-maintain-Merlin-API-as-is*. Instead - the questions of what *release* actually means should discussed in a lot more detail (and on the dev list - not here). In particular, we need a release plan that outlines what aspects are volotile, what aspects are not.
Ok, let me try and rephrase in a more succing way what you are saying: ;-P
1 Merlin/the evolution of it, will be the next Avalon container
Maybe, maybe not - if this process foldes out how I would like to see it fold out - the subject of which container becomes totally academic because everthing is hitting the same back-end API.
2 Fortress will not go away because it will deal with legacy components
Yep.
3 Merlin needs milestone releases to get more feedback
There are other people here who want to get involved in its development/evolution. Getting releases out (similar to the Maven approach) provides binary drop-points, which in turn provide greater flexibity for people to jump in and do stuff inside Merlin (JMX, JNDI, Service Selection, distribution, etc.) against the CVS and greater opportunity for people to lock in against binary relases - from this comes more feedback and participation.
I agree with 1, 2.
Not with (3) ?
I'd add another point: to become (1) Merlin must adopt common standard contacts, which it currently does not always do, as Berin *correctly* pointed out (hence the "divergent" bad work that got you more concerned than IMHO was in the original intentions).
Let's not repeat the same bad habits. If there is something "divergent" then say what it is. I think it is time to drop this rather feeble line of insinuation. If there is something you (or Berin) want to address then get to the point and say it - because neither of you have managed to articulate anything concrete. If its just there to create a negative context then ask yourself the question - why do you think it is necessary to do that? I'm confident both you and Berin will get past the point of having to having to cast dispersions - but maybe is a chair thing and beyond your respective control ;-).
As to you question concerning "what does Fortress provide as legacy that Merlin will not provide and why". There are lots of options and I'm not about to forecast which is best. Fortress is light-weight - lighter than Merlin. There are open questions about how much Fortress should include from a common containment platform - the choice between lightweight as opposed to feature-rich. But this kind of question is academic. If we do things well with respect to containment API, much of this should be configurable (including things like selection of the semantic assumptions). Think of it like this - you run up your container in accordance with a configuration that suites the deployment context you want to establish. And when someone asks you which container your using - you just look at them with a expression that suggests you don't understand – you think about for a moment - then you twig - and you answer - Avalon.
Cheers, 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]
