Fade out Eclipse Platform support?

[spoenemann]

Today I tried to set up the development environment for ELK on my new laptop. I started the installation via Oomph, but it did not work due to some inconsistency with Xtext versions. So I started cloning the repository myself, importing the projects into Eclipse and setting everything up, a very tedious process as you can imagine. This led me back to a thought that I've already had for some time:

Shall we fade out support for the Eclipse Platform?

I know it's a radical change with many ramifications. If we do it, of course there would be a period where we would still publish bugfix versions of the Eclipse plugins. But the ultimate goal would be to get to a core library that is built with plain Java + Gradle or Maven, with any IDE you like (Eclipse, IntelliJ, VS Code, etc.) Additional tools could still be built based on the core library.

To get an impression of what I'm talking about, please have a look at this proof of concept:
https://github.com/spoenemann/elk-core

To build it, simply clone it and run ./gradlew build. Use Buildship if you want to import it into Eclipse. A project setup like this would make it considerably easier for anyone to contribute to the project.

What do you think?

[uruuru]

No major objections from my side. The last time I worked on ELK, I struggled with setting up the environment as well.

A project setup like this would make it considerably easier for anyone to contribute to the project.

I would even go further: it may be the only way to get people to contribute at all.

Some remarks though:

• I felt working on and debugging an algorithm wasn't really possible without the visual support of the eclipse-based views.
• There are several further algorithms and packages that I would expect to easily work without the eclipse platform than contained in your current example.
• How would you solve the definition of layout options, i.e. core.meta?

[spoenemann]

I would even go further: it may be the only way to get people to contribute at all.

I agree.

I felt working on and debugging an algorithm wasn't really possible without the visual support of the eclipse-based views.

We can keep some Eclipse-based tooling for testing and debugging. But those tools would be separate from the core modules and will not be published anywhere. And we can add other tooling that is independent from Eclipse, for example a command-line tool that reads an input graph and generates a png image. In many cases, that's already sufficient to debug certain issues.

There are several further algorithms and packages that I would expect to easily work without the eclipse platform than contained in your current example.

Yes, that was just an arbitrary selection as proof of concept.

How would you solve the definition of layout options, i.e. core.meta?

Option 1: Just use the Java API (what is currently generated by the metadata language).

Option 2: Define a JSON / YAML syntax for that content.

[soerendomroes]

I currently only use this ELK Setup together with the Keith Stream in our semantic setup to install everything we have into one Eclipse.

Option 1: Just use the Java API (what is currently generated by the metadata language).
Option 2: Define a JSON / YAML syntax for that content.

I support both options. Just yesterday I tried to install ELK into a development Eclipse for Lingua Franca and it was very annoying since the ELK SDK would not install.

I will talk to the group about it but I guess it would be the right decision to do this. I am currently working on the 0.8.0 release and plan to upgrade xtext and possibly java in 0.9.0, maybe it would be the right time to do this together with the 0.9.0 release (which is hopefully this year).

[soerendomroes]

The group supports this idea. For which IDEs do we want to support debugging views/stuff? Eclipse, IntelliJ, VS Code?

[spoenemann]

IDE-based tooling should probably stay in Eclipse Platform to avoid reimplementing stuff. But it would be great to add platform-independent (CLI-based) tooling that you can use anywhere.

A big question remains: How long shall we maintain the Eclipse plug-ins, e.g. for GMF integration? Who is still using the Eclipse extension points of ELK?

I have used ELK only through Maven dependencies in the last five years or so.

[soerendomroes]

The extension points will be removed with the upcoming release #760

I guess the Eclipse-based views/preference pages/layout plugin creation wizard will still be provided via extension points. Also someone seems to want to use the graphiz.dot layouter, which specifies some extension points but I guess they are not in use. I know of no one that uses the layout connectors but I guess we will only see if we remove them.

We currently use core.service, which has Eclipse dependencies, to run two layout runs after each other for true interactive layout. If I remember correctly I proposed to remove the dependencies in #762 but I somehow never actually did it. Currently, I am unsure why not?

[pcdavid]

Who is still using the Eclipse extension points of ELK?

Sirius does. For example here. I'm not that familiar with Sirius's ELK integration (@lredor is the expert on that part), so it's not clear to me what the changes proposed here would mean for our integration.
We also have org.eclipse.sirius.diagram.elk.ElkDiagramLayoutConnector which was based on org.eclipse.elk.conn.gmf.GmfDiagramLayoutConnector. I don't know if it is self-contained or if it would break if Eclipse/GMF-specific parts of ELK were removed.

[spoenemann]

Are you using the UI provided by ELK, e.g. the Layout toolbar button and the Layout view?

[soerendomroes]

@spoenemann I do occasionally.

[lredor]

Are you using the UI provided by ELK, e.g. the Layout toolbar button and the Layout view?

@spoenemann In Sirius, we use the Layout view but it is not used directly by the end-user. It is used to facilitate the customization of a Layout and to see the result of the layout options in the context of ELK without the Sirius "adaptations".
It allows, for example, to detect if the problem is on the ELK side (configuration problem, bug in ELK, ...) or on the Sirius side (in the ELK-Sirius bridge).

[lindhuber]

Who is still using the Eclipse extension points of ELK?

The 4diac IDE uses the extension points and the layout connectors (but without any UI elements provided by ELK).
We've started using the connectors and extension points as a way of future-proofing, so removing them now would certainly have some disadvantages for us.

[spoenemann]

A possible way forward could be to extract everything Eclipse related into a separate repository built with Tycho, and to build the core repository with plain Maven or Gradle. But this would require volunteers to maintain the Eclipse plug-ins and build. Is anyone interested in doing that?

[soerendomroes]

We are one of the primary users of these plugins and could put them in the Kieler organization but currently, I don't have that much time. But I could find this time in July or August.

[soerendomroes]

Maybe it is a better idea to just split the repository in the eclipse organization. This would have the advantage that ELK is not dependent on your infrastructure and that the location of the update site must not change.

[spoenemann]

Yes, the code should stay at the Eclipse Foundation. You can request a new GitHub repository at the Help Desk:
https://gitlab.eclipse.org/eclipsefdn/helpdesk

I might be able to help with setting up the core repository. Questions we need to clarify first:

• Which plug-ins should stay in the core repo? My take: all those that are currently published to Maven Central (https://repo.maven.apache.org/maven2/org/eclipse/elk/). Anything else?
• Build with Maven or Gradle? I'd clearly prefer Gradle.