-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fade out Eclipse Platform support? #799
Comments
No major objections from my side. The last time I worked on ELK, I struggled with setting up the environment as well.
I would even go further: it may be the only way to get people to contribute at all. Some remarks though:
|
I agree.
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.
Yes, that was just an arbitrary selection as proof of concept.
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 currently only use this ELK Setup together with the Keith Stream in our semantic setup to install everything we have into one Eclipse.
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). |
The group supports this idea. For which IDEs do we want to support debugging views/stuff? Eclipse, IntelliJ, VS Code? |
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. |
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 |
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. |
Are you using the UI provided by ELK, e.g. the Layout toolbar button and the Layout view? |
@spoenemann I do occasionally. |
@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". |
The 4diac IDE uses the extension points and the layout connectors (but without any UI elements provided by ELK). |
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? |
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. |
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. |
Yes, the code should stay at the Eclipse Foundation. You can request a new GitHub repository at the Help Desk: I might be able to help with setting up the core repository. Questions we need to clarify first:
|
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?
The text was updated successfully, but these errors were encountered: