On Fri, Apr 16, 2021 at 7:34 AM Christoph Läubrich <lae...@laeubi-soft.de> wrote:
> > PDE to properly descibe/support this > > I don't think this is part of PDE but should be part of the > "model-editor"/E4 support as it does not really has a meaning outside > this scope. > > > by 4.20 > > as this feature is optional I think there is no need to rush as nothing > hurts if users are just aware/using it from by 4.20+ ... I believe you see the change from a narrow angle and underestimate its impact of this change in term of "development model" and strategies of extensibility. Extensibility of the Platform is its core value, the one that has allowed it to be successful for such a long time. Success in term of extensibility was achieved by making it high quality: with tools, with documentation, with backward-compatibility and so on. An extensibility approach must not be seen only from a runtime perspective, but also, and probably more importantly from a developer experience perspective. Here, the proposal to use a MANIFEST header is a new model, and until it's not backed by solid documentation and tools, it will be a bad quality way to deal with extensibility because of the story being incomplete. I'm personally against adding into Platform runtime and its maintenance duties some features that we don't plan to finish correctly. For such a new extensibility model, correctness includes tools and documentation. So without a commitment that tools and documentation will be implemented and are part of a plan, I would rather see the runtime part removed and its inclusion delayed. For those reasons, I'm moving back to the idea that despite some technical limitations and require slightly more boilerplate, using Services would be better here: we already have a proper developer experiences for services (via DS at least) with a way to document and some tools to assist in its good usage. Sure, there is an impact on bundle activation and classloading, but frankly, from Eclipse Platform perspective and its typical use-cases, I don't think we have to see this as a major con. Even some "esoteric" use-cases of Platform (eg e(fx)clipse) seem to prefer extra-activation via services over extra-MANIFEST attribute I think that going to service/DS is a more pragmatic way forward, that its value seems easier to leverage in other cases, and will cost much less effort in building a good developer experience because almost everything is already in place.
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
