Migrate the e4 tools to PDE

[vogella]

e4 tools should IMHO be part of of PDE. These tools include for example,

• The application model editor
• Templates for model fragments

They were originally migrated to platform because of "the e4 people are mainly active in platform" (quote from memory).

I suggest we migrate them to PDE so that the plug-in tools get complete.

[laeubi]

Can you explain what PDE has to do with E4? I don't really see any relation here.

[vogella]

The e4 tools provide the tools to develop e4 application and plug-ins, e.g., the wizards to create application model fragments and the model editor. Did the "e4" part confuses you? It used to be the project name which developed the tools. The spies were also part of the e4 tools and we migrated them a while ago

[mickaelistria]

PDE is about tools for Eclipse plugin development. e4 tools are tools for e4 plugin development, maintenance and monitoring. So any tool that is not targetting end-user of the IDE is most likely better fit in PDE.

[laeubi]

So any tool that is not targetting end-user of the IDE is most likely better fit in PDE.

I must disagree here. One can use PDE for plain OSGi devlopment (and I do this for years) while E4 is a way to develop the RCP Framework what is a UI Framework ...

So if we decide that E4/RCP is not part of platform, it might be better to have a dedicated E4/RCP project than to move responsibilities to PDE that is already low on contribution resources.

PDE might include some extensions to E4 (spies?) that are closely related to OSGi, but pushing the burden of E4 UI in general is a bit to much, or for the same arguments we should push all P2 UI > Platform UI because these are actually UIs used in the Eclipse IDE ...

[vogella]

One can use PDE for plain OSGi devlopment

Yes, and for pure 3.x RCP development

[akurtakov]

Being part of PDE or Platform would not affect people working on it as it's pretty much the same group. The separation should be functional in order to make our build and release procedures more straightforward. From https://eclipse.dev/pde/ :
The Plug-in Development Environment (PDE) provides tools to create, develop, test, debug, build and deploy Eclipse plug-ins, fragments, features, update sites and RCP products.

^^ Should be the guiding force whether something belongs in PDE or not.

[laeubi]

Well then we can actually merge everything to PDE that would simplify things a lot ;-)

The question for me is more would someone probably use the E4 tools without PDE because what I defiantly would avoid is to limit the ability of PDE to move forward just because some find a dependency to PDE problematic as seen in

• Add LSP supporting libraries eclipse-platform/eclipse.platform.releng.aggregator#1476

[akurtakov]

Well then we can actually merge everything to PDE that would simplify things a lot ;-)

The question for me is more would someone probably use the E4 tools without PDE because what I defiantly would avoid is to limit the ability of PDE to move forward just because some find a dependency to PDE problematic as seen in

* [Add LSP supporting libraries eclipse-platform/eclipse.platform.releng.aggregator#1476](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/1476)

Actually, one can not use E4 tools without PDE as they have hard requirement on pde.core/ui bundles. Such a move would reduce the circular deps between pde and platform and actually allow PDE to be its own project sooner and thus being able to use LSP in PDE sooner too.

[mickaelistria]

@vogella I think there is a strong enough consensus here if to apply the suggested migration. Now it's up to anyone interested enough to do perform it ;) Here is a link where I've described a way to do it: https://www.eclipse.org/lists/eclipse-dev/msg12214.html

[merks]

Of course such a move makes PDE depend on EMF. But then everyone love to depend on EMF! 😱

[akurtakov]

Of course such a move makes PDE depend on EMF. But then everyone love to depend on EMF! 😱

PDE depends on EMF already (although transitively through Platform).

[vogella]

@vogella I think there is a strong enough consensus here if to apply the suggested migration. Now it's up to anyone interested enough to do perform it ;) Here is a link where I've described a way to do it: https://www.eclipse.org/lists/eclipse-dev/msg12214.html

Thanks for the link, I will try to pick with up for the next release.

[laeubi]

Thanks for the link, I will try to pick with up for the next release.

Please take into mind that in addition to @mickaelistria instructions one need to carefully look for merges/moves and include those pathes when create the filtered repository or otherwise history will be incomplete!

[HannesWell]

@vogella can you please specify in more details which project/classes you suggest to migrate?

Actually, one can not use E4 tools without PDE as they have hard requirement on pde.core/ui bundles. Such a move would reduce the circular deps between pde and platform and actually allow PDE to be its own project sooner and thus being able to use LSP in PDE sooner too.

That is a valid argument for me.
If I'm right that you, Lars, are talking about the Platform-Plugins Ed listed in #826 (comment), it means that this should be all (non-test) dependencies from Platform to PDE?
So that chain would be already broken, which I think is good.

[vogella]

If I'm right that you, Lars, are talking about the Platform-Plugins Ed listed in #826 (comment), it means that this should be all (non-test) dependencies from Platform to PDE?

All / most of https://github.com/eclipse-platform/eclipse.platform.ui/tree/master/tools, need to check in detail.

[laeubi]

@vogella will you take care of this as soon as master is open?

[vogella]

As a volunteer who works on Eclipse in his private time, I cannot commit to any deadline. Anyone who wants to do it, can take the work.

[laeubi]

See

• Migrate the e4 tools to PDE #1081
• Remove 'tools' from repository eclipse-platform/eclipse.platform.ui#1581

[laeubi]

Seems nothing needs to be adjusted at aggregator build for this change.