Niclas, Excellent [RT]! I've been meaning to reply to it since Saturday. You hit a number of things that I and others have been mumbling about on this list for a while.
> -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > > Writing long RTs can have the downside of generating long replies ;o) > > On Monday 03 November 2003 23:09, Berin Loritsch wrote: > > Niclas Hedhman wrote: > > > 1. Naming and Identification > > > 2. Versioning > > > 3. Dependencies > > > 4. LifeStyle > > > 5. Container/Environment Requirements > > > 6. Third-Party Requirements > > > 7. Javadoc and other documentation. > > > 8. Internationalization & Localization > > > 9. Management Interface > > Ok. With 1, how do you think it should work? Right now we have the > > ServiceManager to access the components we need, and we map it via > > the @avalon.dependency tag. Or are you thinking of something else? A bit off-topic perhaps, but Berin's comment reminded me that (as Stephen once pointed out) the ServiceManager serves as two roles: dependency resolution and service discovery. Currently in Merlin, only the dependency resolution is handled. I started mucking around with service discovery but got side tracked. A solution in this area will help complete Merlin and also provide some a place to start working on the 'distributed container' issues that are brought up from time to time. > Container Extensions > ================ > In rare occassions a Component Implementation may require a particular > Container Extension to be present. > Container Extensions are slightly outside the scope of this RT, so I leave > it > as a special dependency case. We have only the beginnings of an extension API in place. Enough to supply basic needs, but not a real solution. This is another one of those 'needs to be addressed' issues. > Assembled Applications > ================== > I have been struggling with the question "Does an Assembled Application > have its own code?" > The argument is that you need some level of GLUE between the Components to > make them work. > The counter-argument would be that, that GLUE is in itself a Component > Implementation, that implements an "Application Component API". > The more I have investigated the "counter-argument", the stronger I > believe in it. One would establish a few "Application Component API"s for > different similar applications. > That would then mean that an Assembled Application is ONLY the components, > and > the "configuration" and "wiring" of these components (Merlin terms; > block.xml, Phoenix terms; configuration.xml + assembly.xml ). This is a really good point. In one of my recent applications, this 'glue' code was a 'controller' component which was essentially a state machine that routed messages between other components. Yet in the end, the controller was definitely a component all of its own. In the end I had several smaller projects each with their own src tree (the various components) and one project with no code, just the 'wiring' configuration files. I haven't been completely happy with this approach and would rather have something like this tool your describing (see the "[RT] My Merlin Wish List" thread I started a while back [1]). As for packaging specifications, I once started listing all the packaging forms in Avalon [2], but since then there's a new one for Merlin: ".bar" Stephen will have to explain this one more, but basically it's a jar'ed repository. I'm really interested in what you're doing and as I finish reading the email thread, I'll probably have a bit more to say. J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg08952.html [2] http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonDeployables --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
