Achim,
> - I see that you're using the concept of natures on modules, > extenstion points and extenstions, where XML would be an example of > such a nature. That looks like a very interesting idea. As you don't > have a defined interface for these natures it seems to me that they're > more like adapters. > I was inspired by the eclipse natures (for example a tomcat nature) which provide additional information to a project. The adapter pattern usually deals with conversion of incompatible interfaces which is not the case here.
I see. What confused me was that the way I've seen Eclipse project natures being used is that they must implement a defined lifecycle interface which allows them to hook in certain behaviours when the nature is first added and when it's removed. It seems like your natures can really be any POJO and can / will be used by any other object whenever required. I thought this was more similar to the IAdaptable interface used throughout the Eclipse APIs (according to the following article this is really an example of the extension object pattern: http://www.artima.com/lejava/articles/designprinciples.html). Also EMF is using something similar they call adapters but aren't truly adapters in the GoF pattern style.
> - The configuration points also seem to declare a constructor which is > responsible for constructing the container object. Is here the idea > that a configuration can have multiple containers (as currently with > Map and List) and thus constructors? > No, I decided to break backward compatibility here. A configuration must have exactly one type. IMO the support for mappable configurations in hivemind 1.x is simply a concession to the need for different configuration types. If you need a configuration as map and list, then define and inject it as map and call map.values(). Migration is quite easy.
OK. I wasn't quite clear on the idea there.
> - In the org.apache.hivemind.definiton package the concrete > ExtensionDefinition objects are not owned by the *ModuleDefinition* > object but instead directly to the respective ExtensionPointDefinition > object. I get the impression that this couples modules in such a way > that it isn't possible to define them independently. IMO it would be > better to keep the ExtensionDefinition objects under the > *ModuleDefinition* object and have a reference by ID to the > ExtensionPointDefinition. > Both is possible. The direct addition to the extension point is the most comfortable way if you define a complete module. Additionally it is possible to define "unresolved" extensions that reference the points by id. The corresponding methods are defined in RegistryDefinition in the moment and here you are right, they should be moved to ModuleDefinition.
IMHO I think the "comfortable way" could be implemented by a implementation of the registry definition API specific for defining modules in plain Java code (as in your example).
> - IMHO defining the *Definition objects as interfaces would have some > advantages. > Ok, but I would introduce interfaces when the api is stable.
Makes perfect sense.
> Anyway I think this is looking very good. Let me know if there's > anything I can help you with. > A most welcome addition would be a refactoring of the dependency injection. It's coupled with the xml specific BuilderFactory in the moment, which makes it difficult to reuse with pure java or annotated java modules.
Maybe we could reuse code or the concepts from commons proxy for this. --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
