[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Extensibility of the application model
|
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 for that
I don't think it needs a dedicated project to implement an extension
point, simply adding this to e4.tools that already manages the
creation of application and fragment models fits well.
+1
I don't think there is a real need for more flexibility.
E4 is not the only one that might provide custom headers and could
profit from tooling support.
Exactly, Eclipse Passage needs it as well. And I'm sure that PDE itself
can add more useful validations for "standard" headers.
that's better to support directly in the MANIFEST.MF and related
existing builder themselves.
Good point, I'll identify necessary extension points and open
enhancement requests to PDE, started already with:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572919
I added my comments to the bugzilla record.
Regards,
AF
Am 16.04.21 um 18:55 schrieb Mickael Istria:
On Fri, Apr 16, 2021 at 5:04 PM Dirk Fauth via platform-dev
<platform-dev@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>> 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 is my
understanding here incorrect?
PDE does contribute the DSEditor. IMO, PDE is pragmatically the best
component where to add support for a new MANIFEST.MF header. Sure,
one could start a new dedicated project for that, and make the
MANIFEST.MF editor extensible so that the new project would
contribute support for an extra header, and then you'll want to make
sure this new project plugins are part of the SDK build; but then it
becomes a matter of months before full completion of that task and it
would require more maintenance.
Concretely, I don't see a better alternative to just supporting this
feature directly in PDE MANIFEST.MF editor; and I don't think there
is a real need for more flexibility.
> - create builder that scans manifest and add error markers (e.g.
file not present), and scans for plugin.xml with "old" fragemnt
registration
Would that require all plugin projects to add the builder to their
.project? That wouldn't be a pleasant thing to introduce such
requirement to leverage this new core extensibility model. This is
IMO a feature that's better to support directly in the MANIFEST.MF
and related existing builder themselves.
> - add qucik-fix to the marker to help assisting in fix the problem
(e.g. convert plugin.xml->manifest header)
This is not a requirement for proper usage. There is no compelling
reason to encourage people who use a plugin.xml to use a MANIFEST
header instead, and since the MANIFEST header wouldn't be backward
compatible, it's dangerous to recommend it before a few releases when
we can expect most of the consumer market is using a compatible release.
So IMO it's best to not touch that part for the moment.
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev