Hi,
with regards to the tooling:
the simplest thing would be to change/extend the wizard to write the manifest header instead of creating and registering the plugin.xml.
with regards to the lifecycle:
Christoph is right that the manifest header with the bundle tracker is more equivalent to the extension point thing than using DS. Although I think for the Eclipse Platform it should not really matter as all bundles should be registered and via DS at least in STARTING state before the ModelAssembler is starting doing its work.
with regards to the predicate:
IIRC you would need to extend the ModelAssembler to respect a Predicate, right? So actually you could even extend the Manifest header and add a new filter property for example, that actually does the same. So from a functionality point of view I think this would be also possible.
As I said, I don't have a strong feeling about the implementation details anymore. IMHO both is possible. From a plain OSGi point of view the Manifest header should be preferred. From a Platform point of view it is discussable because of the mentioned points. Although I am not sure about possible Lifecycle issues. Extending the tooling should be not too complicated.
@Tom
Just for a better understanding, would the Manifest header a big point for e(fx)clipse?
Whether you are active at the moment or not, your opinion is important as you have a very detailed understanding and are an adopter of the Platform in a non-standard way. And in the past we did a lot of cleanups to make the Platform consumeable in various scenarios.
Greez,
Dirk
