Achim,
On 5/21/05, Achim Huegen <[EMAIL PROTECTED]> wrote:
>
> >
> > I had something different in mind. Something which much closer
> > resembles what the current API with the *Descriptor classes looks
> > like. Just interfaces instead of classes and with XML specifics
> > stripped of. So for example:
> >
> > public interface Contribution
> > {
> > String getExtensionPointId();
> > Object[] getElements();
> > }
> >
> > There would of course be an "owning" Module interface with a
> > getContributions() method to establish the module relationship.
> >
> > An implementation of this interface would return the
> > SymbolSourceContribution objects with a call to getElements(). The
> > implementation could then chose to implement a lazy loading strategy
> > or not.
> >
> > Does that make sense?
> >
>
> I see what you mean and it does make sense.
> Probably in ContributionDescriptor the getElements method would be replaced
> with:
>
> public Contribution getContributions()
>
I thought that instead the ContributionDescriptor class should
implement the Contribution interface I described.
>
> What is still bothering me is that it's so much work just to contribute one
> object
> to a configuration. You have to implement a ModuleDescriptorProvider, that
> returns a ModuleDescriptor, which contains a ContributionDescriptor which
> finally
> returns the Contribution.
That is exactly what I thought we should try to simplify. I was
thinking of a RegistryBuilder with a simple addModule(Module) method,
where the Module interface looks something like:
public interface Module
{
Set getServicePoints();
Set getImplementations();
Set getInterceptors();
Set getConfigurationPoints();
Set getContributions();
Set getSchemas();
}
It should also be possible to implement a "pull API" like
ModuleDescriptorProvider on top of this.
> The main task of RegistryInfrastructureConstructor is to unroll these
> hierarchy
> and finally call ConfigurationPoint.addContribution()
> And that's what I would like to call directly. This could be the core API
> that is used by RegistryInfrastructureConstructor. I would even refactor
> RegistryInfrastructureConstructor and extract all ModuleDescriptor specific
> parts
> to another class (ModuleDescriptorProcessor?)
>
I'd say the main task of RegistryInfrastructureConstructor is to pull
together all extensions (speak: implementations, interceptors, and
contributions) from the various modules and add them to the respective
extension points. But I agree with you, there is a core API below this
level in which a module only contains extension points, which contain
their extensions. This core API does exist, but IMO it contains some
things which really belong to this "registry construction API" I'm
trying to come up with.
To respect HiveMind's concept of modules (with distributed extensions)
I think the Java API you'd like to see would have to be implemented on
top of this registry construction API. But that should be possible,
no?
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
