Migrated eclipse.ui/SWT dependencies.

[soerendomroes]

The core.service plugin bundles functionality that is currently Eclipse dependent, but could be used outside of an Eclipse context (such as the DiagramLayoutEngine). I suggest to split the core.service plugin in an Eclipse dependent and independent part.

Ideally, we would want to do this also for downstream projects. For Klighd we decided it would be best to mock SWT und eclipse.ui instead via package dependencies and a mock plugin. The other alternative to deeclipsify Klighd would be to do something similar to the changes here and split every synthesis into three parts, which is why we don't want to do this now and try to mock it instead.

The DiagramLayoutEngine is currently used for interactive layout using a language server (or KIELER). However, we do not need the eclipse dependencies in that case. Moreover, we are working on a general diagram server/VSCode plugin and others to be able to use this too without understanding our whole build infrastructure. Currently, we have to supply three language servers for this. With an eclipse independent ELK (and Klighd) this does not have to be the case.

tldr: We need the not-eclipse-dependent functions and currently have dependencies to eclipse, which we start to elimate beginning with ELK.

Signed-off-by: Soeren Domroes sdo@informatik.uni-kiel.de

[sailingKieler]

General question: What is the motivation for/benefit of these changes?
Or other words: What are use cases that cannot be solved with the existing architecture?

Please add @spoenemann as reviewers, as he designed the current state.
What about @le-cds?

[soerendomroes]

General question: What is the motivation for/benefit of these changes?
Or other words: What are use cases that cannot be solved with the existing architecture?

@sailingKieler I added a short description of the use case to the PR description.

[spoenemann]

I have not used the Eclipse-specific integration in the last five years or so. I would be fine with dropping that part completely if it's too much effort to maintain it. We should rather reduce ELK to its core value, a layout library for Java, than complicating things too much. But feel free to do the splitting as you proposed 👍

[soerendomroes]

An alternative to this approach would be to migrate Eclipse independent more general classes in an own plugin instead of more eclipse dependent in a new one.
Pros:

• Interface remains the same for Eclipse users
  Cons:
• service.core plugin moves into a new feature

[uruuru]

Same opinion as Miro.

[soerendomroes]

@le-cds If you have nothing to add I am willing to merge this

[soerendomroes]

I think this is no longer necessary.