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()
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.
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?)
Achim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
