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.

• https://github.com/eclipse-platform/eclipse.platform
  [Oomph-Setup] Add eclipse.platform configuration setup eclipse.platform#1582
• https://github.com/eclipse-platform/eclipse.platform.ui
  [Oomph-Setup] Add eclipse.platform.ui configuration setup eclipse.platform.ui#2363
• https://github.com/eclipse-platform/eclipse.platform.swt
  [Oomph-Setup] Add eclipse.swt configuration setup eclipse.platform.swt#1509
• https://github.com/eclipse-equinox/equinox
  [Oomph-Setup] Change Equinox configuration setup to contain only equinox eclipse-equinox/equinox#689
  • Should also include https://github.com/eclipse-equinox/equinox.binaries
• https://github.com/eclipse-equinox/p2
  [Oomph-Setup] Add equinox.p2 configuration setup eclipse-equinox/p2#557
• https://github.com/eclipse-jdt/eclipse.jdt.core
  [Oomph-Setup] Add jdt.core configuration setup eclipse-jdt/eclipse.jdt.core#3071
• https://github.com/eclipse-jdt/eclipse.jdt.debug
  [Oomph-Setup] Add jdt.debug configuration setup eclipse-jdt/eclipse.jdt.debug#533
• https://github.com/eclipse-jdt/eclipse.jdt.ui
  [Oomph-Setup] Add jdt.ui configuration setup eclipse-jdt/eclipse.jdt.ui#1710
• 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

• 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.