Re: Component Discovery and Resolution

Berin Loritsch <[email protected]> Tue, 18 Mar 2003 08:14:40 -0500
Newsgroups gmane.comp.jakarta.avalon.phoenix.devel
Message-ID <[email protected]>
Leo Simons wrote:
> Berin Loritsch wrote:
> 
>>> @avalon:info.name <name>
>>> @avalon:info.version <version>
>>> @avalon:info.attribute <key> <valaue>
>>>
>>> Where avalon:info.name equates to Fortress/ECM shorthand name?
>>>
>>> One other thing, in the background work I've been doing I'm using the 
>>> URN convention of <domain>:<key> - i.e. "avalon:something.whatever.etc".
> 
> 
> Specifically, if it is possible to not use services.list in favor of 
> using the blah.xconf setup phoenix uses and accomplish the same thing, I 
> would strongly prefer that. I am guessing the ng/ stuff in fortress 
> accomplishes exactly or some of that (though I haven't looked at it).

As it is now, each container has their own assembly and configuration
info.  We *could* directly generate a *.roles file, like is done with
Fortress's ConfigurableRoleManager--but we loose the runtime culling
of all the types available.

For now, all we need to do is to say that to use this feature (which
won't be made the default) you have to use the ANT tasks to preprocess
your JARs.  That way we can provide the assembly tools as part of each
container, and users will be accustomed to that process.

The exact placement of everything is only useful from the standpoint
of using generative programming to create new components at runtime.

> In general, if it is at all possible and sensible to use the phoenix 
> metageneration tasks, the phoenix tag conventions, the phoenix 
> configuration file locations, etc etc, then that is the right thing to 
> do for fortress, merlin, etc. It will make life so much easier when 
> implementing any kind of "spearhead", and it makes applications (not 
> just components) cross-container to a larger extent.

We have to get there one step at a time.  Right now, the user has to
deal with different ways of *expressing* meta information.  This is
the first step toward resolving that part of the puzzle.  Fortress is
meant to get people who were dependent on ECM to appreciate the new
features of the newer set of containers.

For the Merlin rollout, I would like us to focus on assembly standards
and tool standards.