I see an issue about the general "Allow contribution of addition Manifest
header checks" but I don't see one about the specific new Model-Fragment
MANIFEST header. Can you please create one and make
https://bugs.eclipse.org/bugs/show_bug.cgi?id=571866 link to it?
Thank you Christoph for starting this effort!
4/16/2021 9:07 PM, Christoph Läubrich пишет:
Someone recently wrote
Extensibility of the Platform is its core value
so it seems logic to me to add to this value and make PDE more
extensible here :-)
+1
could start a new dedicated project
On Fri, Apr 16, 2021 at 5:04 PM Dirk Fauth via platform-dev <
platform-dev@eclipse.org> wrote:
> Well, is it possible to contribute code completion etc to the pde manifest
> editor from the outside? Adding it in pde would be wrong in terms of
> dependency as pde is about osgi and not platform. Or
I'm currently investigating on how this could be done, but any tips are
welcome.
Current plan is:
- create builder that scans manifest and add error markers (e.g. file
not present), and scans for plugin.xml with "old" fragemnt registration
- add qucik-fix to the marker to help assisting in fix
On Fri, Apr 16, 2021 at 2:57 PM Wim Jongman wrote:
> Mickael, what would need to be done to accept this new strategy?
>
Commitment that quality tools (at least completion/hover/validation in
textual MANIFEST editor) and documentation (everywhere the model fragment
is referenced in
Not every user of platfrom is on the list, not every user on the list
regular participate in discussion. So this is not representative for me.
You can count me as a user of this new feature (that's why I have invest
a lot of time in review, suggestion and even some discussions as well)
and
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
On Fri, Apr 16, 2021 at 7:34 AM Christoph Läubrich
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
> 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
Hi,
I tend to disagree that we only want to contribute static data, if we
use a service approach, we could eg in future add Predicate-Support (eg
only merge that feature if you starting on locale-xyz, ...).
I think we should provide ONE extension story and not multiple who are
not really
Hi,
Thanks Dirk for bringing the thread; and thanks Dirk for
clarifying how a MANIFEST header is much more interesting than a service.
That is IMO per se a good reason to stick to MANIFEST header and not
"regress" to an OSGi service.
So my concern is not any more about the technical aspects, but
What if we will reserve a default location inside OSGI-INF (say,
OSGI-INF/e4/fragment.e4xmi) and then implement a header in the
MANIFEST.MF just to override the default.
Similary like it was done for "Bundle-Localization:"
Regards,
AF
4/15/2021 9:24 AM, Christoph Läubrich пишет:
First of
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
13 matches
Mail list logo
