avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject RE: [RT] Block Packaging
Date Mon, 03 Nov 2003 23:10:41 GMT

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:niclas@hedhman.org]
> 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

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
  (724) 696-7653

[1] http://www.mail-archive.com/dev@avalon.apache.org/msg08952.html
[2] http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonDeployables

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message