-
Notifications
You must be signed in to change notification settings - Fork 77
Eclipse IDE ‐ Developers Community Call
Upcoming and past meetings are listed in the Eclipse IDE Community
calendar
Everyone that participates or is interested in participating in the development of the Eclipse core itself is invited to join, newcomers are explicitly encouraged to join too. It is planned as an open meeting without a fixed agenda, where everyone can suggest to discuss general or specific topics, changes or issues or can ask questions. This call is dedicated to the development of the core of Eclipse itself, mainly the top-level projects Eclipse-Platform, Equinox, Eclipse Java development tools (JDT) and Eclipse Plug-in Development Environment (PDE). It is not intended to provide support for users or consumers of Eclipse, for that other channels exists. If specific issues or changes are discussed, the exchanged arguments should be summarized in the corresponding issues or Pull-Requests and if decisions are made they should be justified. Of course others not participating in the call should still have the same chance to influence a decision.
-
The following topics were discussed
- General discussion about 'Corporate Capture' of Eclipse and how it affects the innovation at Eclipse in general and about how to improve the founding situation of smaller, yet essential projects.
- IDE UI "is very chaotic. For example, the context menus are very disorganized. How could they get cleaned up in a meaningful way?"
- Caused by many different contributing projects
- Style guide: https://eclipse-platform.github.io/ui-best-practices https://github.com/eclipse-platform/ui-best-practices
- Reducing duplication and improving the organization requires cross-project coordination.
- Suggestion for more placeholders that can be re-used by different projects in order to reduce duplication in the UI.
- "The documentation is overwhelming for beginners and good resources are hard to find."
- "It's all there but especially the official resources/docs are hard to find"
- "Many unrelated things on the main page"
Suggestions to consider a clean-up of or to make the documentation leaner
Because of overwhelming doc and UI the suggestion was made to discuss if the the position of EPPs Packages should be strengthens with a product-owner for each package that makes sure the default content of these packages looks good and the documentation is cleaned up.
- Where to report issues if the exact project is unknown?
Currently https://github.com/eclipse-platform/.github/issues In the future hopefully in the 'eclipse-ide' GitHub organization
-
The following topics were discussed
- Discussion about the requirement of the Eclipse-IDE respectively the requiring Java-21
- It would be nice to inform the user better during the update-process, for example show a corresponding dialog in the IDE.
- Discussion about if/when Eclipse SDK/top-levle projects should require Java-21
- Set up rules for Eclipse SDK/top-level projects (PMC TODO)
- Suggestion to add code that uses
- Code that uses Java-22 Foreign Function and Memory Access API could be placed in dedicated fragment to be usable before Java-25 is used in general.
- Appeal to re-use existing images or shared images to not replicate e.g. a close icon in 20 bundles (which is currently the case).
It unnecessarily increases the size of an installation, the required memory at runtime and the time to load all images.
Problem: Icons are resources and not 'API'.
- Images in platform plugins are quite stable.
- Suggestion: Generate constants (e.g. by PDE) that represent contained resources and provide coordinates to access them. The class and its constants are API and therefore the resources implicitly become part of the API, which can be checked with existing tools. Issue created: https://github.com/eclipse-pde/eclipse.pde/discussions/1315
- It should be discussed and stated if the path of the referenced resources within the bundle may change and if the content of the resources may change, while preserving the purpose. E.g. may a close-icon be redesigned while still being a close-icon.
- Short discussion about API-check failures in CI builds due to 'Component was disposed' errors, but no immediate solution is known.
- Discussion about the requirement of the Eclipse-IDE respectively the requiring Java-21
-
The following topics were discussed
- How to simplify the contribution process or what are the current pain-points during contributions, for experienced and new committers?
-
Unexpected build failures
- Due to necessary service/micro version bumps, especially in the beginning of a development cycle
- A concept about a work-flow that automatically creates the necessary version bump commits, based on existing Tycho capabilities, has been discussed.
- Intermittent failure of API tooling Already mentioned last time, see https://github.com/eclipse-pde/eclipse.pde/issues/553 and https://github.com/eclipse-pde/eclipse.pde/issues/1310
- JGit Error in the end of a Tycho-build:
java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText
- Actually harmless but confusing for those that don't know it
- Flaky tests in platform.ui
- Due to necessary service/micro version bumps, especially in the beginning of a development cycle
-
Provide and document a clear way to set up a developer IDE for contributions to Eclipse There should be a "gold standard for how to setup as a new contributor". Of course different ways are possible but one only 'ideal' way should be recommended and described (describing all can be confusing).
- One suggestion was to replace the Eclipse Committer Package by a corresponding Oomph configuration based on the Eclipse-SDK?
-
There is no
Report a bug button
in the IDE that leads to a place where one can start to report a bug or gets instructions how to contribute.
-
- How to simplify the contribution process or what are the current pain-points during contributions, for experienced and new committers?