Provide Oomph setup configuration for relevant repositories individually

[HannesWell]

For the Eclipse top level projects Eclipse-Platform, Equinox, JDT and PDE there is currently only one Oomph Configuration per organization that contains all the project respectively repositories in that organization.

In order to simplify the contribution process there should be one configuration per repository for the following relevant respectively active ones. Having less projects in a configuration means less variables to configure during the setup process and reduces the number of projects in the workspace being set up.

• [x] https://github.com/eclipse-platform/eclipse.platform https://github.com/eclipse-platform/eclipse.platform/pull/1582
• [x] https://github.com/eclipse-platform/eclipse.platform.ui https://github.com/eclipse-platform/eclipse.platform.ui/pull/2363
• [x] https://github.com/eclipse-platform/eclipse.platform.swt https://github.com/eclipse-platform/eclipse.platform.swt/pull/1509
• [x] https://github.com/eclipse-equinox/equinox https://github.com/eclipse-equinox/equinox/pull/689
  • Should also include https://github.com/eclipse-equinox/equinox.binaries
• [x] https://github.com/eclipse-equinox/p2 https://github.com/eclipse-equinox/p2/pull/557
• [x] https://github.com/eclipse-jdt/eclipse.jdt.core https://github.com/eclipse-jdt/eclipse.jdt.core/pull/3071
• [x] https://github.com/eclipse-jdt/eclipse.jdt.debug https://github.com/eclipse-jdt/eclipse.jdt.debug/pull/533
• [x] https://github.com/eclipse-jdt/eclipse.jdt.ui https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/1710
• [x] https://github.com/eclipse-pde/eclipse.pde Already done, because there is only one repository in the PDE organization
• [ ] https://github.com/eclipse-platform/eclipse.platform.releng.aggregator Already has the configuration but misses the advertisement in its README.

All of these repositories should advertise the configuration in a prominent location using the styled button for it, just like it's done for PDE: https://github.com/eclipse-pde/eclipse.pde?tab=readme-ov-file#how-to-contribute

All other repositories are either inactive or are only relevant for advanced contributors and advanced use-cases.

The project definition can stay at the their current location, usually centrally managed in one 'main' repo of an organization. In the configuration they can just be referenced through the global catalog.

Community

• [x] I understand suggesting an enhancement doesn't mandate anyone to implement it. Other contributors may consider this suggestion, or not, at their own convenience. The most efficient way to get it fixed is that I implement it myself and contribute it back as a good quality patch to the project.

[opcoach]

should we add the egit/jgit setup in the list ?

[merks]

Note that egit/jgit are a bit challenging in terms of contribution in that you can only contribute via gerrit not via pull requests.

[jukzi]

Having less projects in a configuration means less variables to configure during the setup process

Is that realy a good goal? All those projects are connected and if you see only one of them you will probably easyly break another that (illegally) uses internals or is an x-friend.

[opcoach]

Note that egit/jgit are a bit challenging in terms of contribution in that you can only contribute via gerrit not via pull requests.

Yes the review tooling is specific... I opened a change on egit 1 month ago and it is still not merged ... the gerrithub configuration is explained in the configuration documentation... we will only mention in eclipse-ide the kind of tooling for contribution (PR or gerrithub).

Is that realy a good goal? All those projects are connected and if you see only one of them you will probably easyly break another that (illegally) uses internals or is an x-friend.

That can be a problem indeed, ... but if a contribution should be done on platform.ui it would be nice to work only on platform.ui and not must be constrained to load also platform... Is there so much x-friend links that goes out of a repository ? I hope no

Keep in mind, that what we propose is for new contributors who will focus on a specific issue. For 'advanced' contributors they will keep their current install if they want, with a global oomph setup that will install all the projects.

[HannesWell]

Having less projects in a configuration means less variables to configure during the setup process

Is that realy a good goal? All those projects are connected and if you see only one of them you will probably easyly break another that (illegally) uses internals or is an x-friend.

While this would nice to avoid the described class of errors you described, I assume a significant number of contributors doesn't have all projects of the Eclipse SDK in one workspace any way. At least I work on the repos forming the SDK from multiple workspaces and not one. It can't be enforced anyway and we already have configurations for Equinox, PDE and JDT that only include only the repositories of the respective projects.

Having all project's in the workspace can not only be overwhelming but can also make working with them inconvenient because it slows down the workspace build. If you apply the Eclipse SDK configuration the variables page looks like this (and the list almost doubles if one chooses to set the absolute path for each repo):

I assume that's not appealing for new contributors and it makes the installation process run longer and the more is done the higher is the chance for trouble. And in the end the workspace is more crowded and it's therefore more difficult to find the desired project. Furthermore it also means that one has to manage more git repositories.

So while having all SDK projects in one workspace has the good effect that problems due to changed internals are hopefully discovered early, I don't think it's worth all the down-sites, especially since it doesn't happen that often. And in the end a failed I-build is IMO not a drama, it's not nice, but something that can often be fixed quickly.

should we add the egit/jgit setup in the list ?

If the same is desired for jgit/egit it should be tracked in their repositories. But due to the mentioned special setup, contributors might benefit from automation even more.

[HannesWell]

The all three active eclipse-platform repositories now have a individual configuration and an 'Oomph setup button' referencing it in their README.

Do you think I should also add one just for the eclipse.platform.releng.aggregator repo?

I'll continue with Equinox and P2 in the next days.

* [ ]  https://github.com/eclipse-jdt/eclipse.jdt.core
* [ ]  https://github.com/eclipse-jdt/eclipse.jdt.debug
* [ ]  https://github.com/eclipse-jdt/eclipse.jdt.ui

@jarthana, @iloveeclipse or @jukzi do you want to have that for JDT as well? Since I'm not a committer a supporting committer that submits my PRs is needed. As a reference, in the end the How to contribute section could look like this with an individualized 'Oomph-setup button' for each JDT repository: https://github.com/eclipse-platform/eclipse.platform?tab=readme-ov-file#how-to-contribute

[iloveeclipse]

do you want to have that for JDT as well?

Why not? It wouldn't harm and may be even help someone to provide a fix, so yes, please. May be you could provide a combined setup including all three JDT repos at https://github.com/eclipse-jdt?

[merks]

May be you could provide a combined setup including all three JDT repos at https://github.com/eclipse-jdt?

A combined setup configuration for all of JDT's git repositories already exists (as it does for each of the Eclipse TLP projects):

https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md#create-an-eclipse-development-environment

[laeubi]

Is that realy a good goal? All those projects are connected and if you see only one of them you will probably easyly break another that (illegally) uses internals or is an x-friend.

This is already a problem anyways not very well covered by the current verification builds (and especially cumbersome for JDT) for platform we have already merged a lot of stuff that makes it less of a problem.

In any case the solution should be to remove the coupling and internal usage, not to force contributors to checkout and mange multiple repositories.

[laeubi]

By the way I would handle platform + platform.ui as one they are only separated for technical reasons (build time) not really semantically and closely related.

Maybe in this case one can either link to one of them or simply copy the file (if its easier) so it does not matter what repo is choosen.

[opcoach]

What about the news and noteworthy if a contribution has to be documented ?

I think It would be nice to have the repository for news and Noteworthy in each setup. But ...

News and noteworthy has been moved from this old location https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/ to a folder 'news' in the https://github.com/eclipse-platform/www.eclipse.org-eclipse

This repository is used to manage the content of ' https://www.eclipse.org/eclipse/' website. So there are a lot of files that do not really concern the 'news and noteworthy'... (some contributions are 19 years old ...)...

There is a contribution guide which is available here https://github.com/eclipse-platform/www.eclipse.org-eclipse/blob/master/CONTRIBUTING.md and it is focused only on 'News and Noteworthy' and not on the other parts of this repository... It seems that it is a copy of the old one....

There are 2 published pages extracted from the 'news' folder : https://eclipse.dev/eclipse/news/ and https://eclipseide.org/release/noteworthy/

This is probably organized like this for technical reasons, but this 'news' folder should be probably hosted in a single repository... Regarding the size for the download, the total repository size is 318 Mb and the news folder is 107 Mb...

What do you think of adding this repository to each setup ?

[opcoach]

It would be nice to have all the E4 spies installed in all the UI setup to help the UI debug ....

[merks]

Does one need them in the host IDE or just in the self hosted launch? The "debugging" comment makes it sound like the latter which would need to be listed here:

Is it this feature you'd want in the target platform?

[opcoach]

Spies should be available to test the launched application ... So not in the host IDE, rather in the self hosted launch. I can't see the images in your comment but I guess you mentioned the org.eclipse.pde.spies.feature or something like that.

In the run configuration proposed in a project, spies should be added on demand.

[merks]

I added the swt spies feature as well for sleak support.

[HannesWell]

Thanks for adding the spies Ed.

But although this issue is almost completed it is not yet fully completed, the configuration for this repo is still pending.

Furthermore I plan to remove the now obsolete eclipse.git.authentication.style variable from the existing configurations: https://github.com/eclipse-equinox/equinox/pull/689#discussion_r1798257151

[akurtakov]

Is there anything still pending here ?

[HannesWell]

Is there anything still pending here ?

Yes, the configuration for this repository, but I try to provide it ASAP to make this complete.