Pete:
Given that ... 1. you cannot realistically use Phoenix for embedded component management 2. you cannot use Fortress/ECM/MicroContainer for components with meta 3. you cannot use Phoenix/Merlin for ECM style component lookup Which container do you want to be the "one" - MicroContainer/ECM/Fortress/Phoenix or Merlin. No matter which decision you take you end up with an incomplete solution. That's my point - the one container principal does not work and will drive against innovation - and this is innovation area. What really matters is consolidation of the achievements in MicroContainer/ECM/Fortress/Phoenix and Merlin - and that means container authors getting there heads together and sorting out what the back-office of component management means. There isn't one solution today - there is no back-office spec. Until that spec is built and a reference implementation established - there will never be one solution. Pete Carapetyan wrote: > Stephen McConnell wrote: > >>> If the other Tomcats would be mostly ignored, what's the point of >>> spending precious volunteer developer time on them? >>> >> >> Because the types of container that exist today are in general >> addressing very differnent problmems. Phoenix is an app-server that >> runs an application where an application is defined as a package of >> components, supporrting resources and assembly directives - Merlin is >> a component runner that just runs up a component + all of its >> dependents - greate for development and massively simplified >> deployment. Fortress is focussed on simple components (relative to >> dependencies) bu provides better support for stuff relating to pooled >> components. All of the containers listed here represent end-points in >> the deployment cycle - Merlin II is addressing the issue of a >> container that is a component in another container's idea of the >> word. The point in spending the time is that we are sorting this >> stuff out - what is container - what should a minimum container be - >> how to seperate container operation form functionality - multiple >> contains mean we have validation of differnent approaches based on >> different objective. > > > And that paragraph just about says it all for me. Jeez Louise. Is this > complexity for the sake of complexity or am I just going cookoo? I'll > second Haberman's motion that good design means a second version is > not warranted in most circumstances. > > But wait, this next paragraph is even better. > >> Thin what an improvement it would be if you could write an ant task >> that automatically executed your single servlet class - did the >> compilation of the JSPs, did the context management stuff - and >> provided lots of debugging info - then imagine that Tomcat had >> another tool - a tool to runup the entire packaged web app and let >> you validate things in a context closer to deployment - then imagin a >> third tool Tomcat itself where you run you web app in a mixed >> environemt with other applications - and still as an ant task - still >> wioth lots of debugging information - and then finally, imagine a the >> final refernce Tomcat - the thing that runs your application out in a >> customer environment. Tomcat does not deliver this - Avalon can. > > > You forgot to mention the new college degree program in Avalon. > Complete with 17 courses of instruction, and four equal department > heads to compete against each other on which one was the real path to > the holy grail. But it's a six year program, couldn't get it done in > four. > > The reason Avalon is complex is that committers get a great deal of > personal satisfaction from making it complex. The only thing that > could be better would be to make it even more complex. Wait ! Here's a > new feature with 3 new permutations. Let's add that too! No, let's > start a whole new container. That's the ticket! Or should it be 3, one > for each permutation? Hmm. <advertisement> Go check out Merlin - its all about eliminating complexity. I can write a new component, and run it with no container configuration - just an ant task and a target component class name. If I don't want to use ant I can do the same thing from the command line. If I don't like that I can embed it inside anther component. And guess what - its all documented and does not need a degree in anything :-) This isn't about complexity - its about simplicity. </advertisement> > > Do one thing. Do it well. Avalon is about good engineering, not more > engineering. There is a difference. The Avalon component model is looking good. The API for the client is small, consistent and complete. However, two operations on one class are the subject of a lot of debate - and guess what - those two operation relate to the interaction between the component and its container. If we look back into the not so distant past - two different approaches were taken by two different communities in the development of tools to handle component management in two different application areas - one was Phoenix and the other was ECM. These two "containers" were basically referred to as applications - then some time later another two applications emerged - Fortress and Merlin. Why? Fortress came about as an evolution and improvement in ECM based component management. Merlin came about as an evolution and enhancement of the development approach related to Phoenix based components. As a result of that - the subject of the "container" came to the forefront. What is a container? What are the differences in the semantic assumptions that exist between the Phoenix family and the ECM family with respect to components? Those things have been thrashed out (and continue to be thrashed out) on this list. Throw into this the fact that the content of a common container framework is not set in concrete - it's emerging. The premise of doing one thing and doing it well is fine providing we know *what* that one thing is - and that we *understand* what doing it well really means. Cheers, Steve. (who's busy digging into *what* and working on the *understanding*) -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
