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 Mickael Istria <mist...@redhat.com> schrieb am Fr., 16. Apr. 2021, 13:03: > OSGi is a technical choice for the Platform, something that is happily > used and provide a lot of value. However, extensibility of the Platform > doesn't have to necessarily be best according to OSGi. It has to be best > according to itself and its targets. > If you look at the only feedback we have from someone (Tom with efxclipse) > who's likely to add model fragments without using the extension point, then > the feedback is that a MANIFEST header is not satisfying and services are > better. It just look like there is more need for services to provide that > than for the header. As such, the header may just be something we don't > need at all and not just something that's postponed. > Concretely, the MANIFEST header seems to be a dogmatic solution with > inferior value and higher cost to compared to the pragmatic OSGi services > approach. > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
