[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-dev] Extensibility of the application model
|
First of all, as mentioned before, DS is an implementation detail!
Actually extensions can be registered by anything else (Activators, CDI,
BluePrint, Remote Service API...) and are just services.
The disadvantage of a service when we are talking about static meta-data
like a fragement.xml is that a service always requires an active/started
bundle and as a consequence the creation of classloader, and probably
initialization of other services and bundles.
On the other hand, Manifest-headers could be inspected even for
unresolved bundles and are widely used in OSGi (DS uses it, JPA Spec
uses it and probably more), some of the using detaults (e.g. we could
declare "/fragment.xml" as the default and make the header obsolete for
the common case).
Beside that, creating an implementation, registering it as a service
just to return a static string (we can't even profit from any typesafty
or compiler checks here) does not sound very clever.
Instead some tooling that detects *.e4xmi files in the project and offer
to add it to the Manifest-header or warning a users if path mismatches
would be much ore helpful.
About the confused user (as this was brought up recently in another
discussion also), we better improve the tools than trying to adjust
technical implementation details to follow a vague 'user expectation',
especially in case of fragment.xml there is a wizard already that setup
everything for the user. If that's not visible enough we should improve
the tooling.
Am 15.04.21 um 08:01 schrieb Dirk Fauth via platform-dev:
Hi all,
I have recently contributed a new way to extend the application model
via fragment and processor that avoids the usage of the extension point.
A model processor can be registered via DS, a model fragment can now be
registered via a Manifest header.
Mickael and Tom have now mentioned on the ticket that the Manifest
header solution for registering a fragment introduces a new way to
extend the application model, which could be confusing for a user.
Instead we should stick with one replacement for the extension points,
which is the usage of DS.
The initial proposal was to have a service that simply provides the
static information for registering the model fragment. In the review
process this was changed to the Manifest header solution to follow the
OSGi best practices as static information inside a bundle does not need
to be provided by a service.
The goal of the new extension is to get rid of the extension points as I
already mentioned. The nice side effect is that with this change it is
even possible to handle dynamics, e.g. add/remove model elements like
parts and menus on installing/uninstalling bundles. This actually works
already for parts, but still needs some work for other stuff like menu
contributions. But I need some support on the model side, as I am not
that deeply familiar with this.
As there is now a discussion in the ticket whether to use DS only or
keep the Manifest header, I would like to move the discussion to the
mailing list. IMHO both ways have their advantages and disadvantages.
Technically both ways are possible AFAICS.
Please discuss and let me know which way to go. The Manifest header
solution is currently in the code base (see ModelAssembler). The DS
solution could be restored/implemented with also not too much work. I
would really like to get the new extensibility in, but of course it
should be a solution that the majority of the Platform committers share.
We are not yet in the code freeze phase, so I would be able to change it
if that is the decision.
For more details have a look at the Bugzilla entry and the patches in
Gerrit.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=571866
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=571866>
https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/177574
<https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/177574>
https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/179290
<https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/179290>
Thanks and hope for a constructive discussion
Dirk
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
