[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Extensibility of the application model
|
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 :-)
> 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.
> 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.
> 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
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