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.