Clarify using eclipse.platform.releng.aggregator for contributions

[kwin]

Currently the document https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md still mentions several GitHub repositories, but I think nowadays it is recommended to use the submodule approach from https://github.com/eclipse-platform/eclipse.platform.releng.aggregator mainly and start building from there.
Also it would be good to add a hint on how to work with git submodules for fixes for the individual bundle repos (JDT, platform, SWT, ...) afterwards.

Also a pointer towards the SNAPSHOT repository containing the most recent SNAPSHOT builds of the Eclipse dependencies (to not force everyone to build everything oneself) would be helpful as it is pretty common still that people us a global corporate mirror for all repositories (https://maven.apache.org/guides/mini/guide-mirror-settings.html).

[mickaelistria]

I think nowadays it is recommended to use the submodule approach from https://github.com/eclipse-platform/eclipse.platform.releng.aggregator mainly and start building from there.

IMO, the aggregator repo is only useful if you want to build the whole SDK, but this is not a common things contributors need. I wouldn't make it the main recommendation; but it can be good to add a "Build the whole SDK and Eclipse Platform repository" section in this doc, for which the aggregator repo would be the main entry point.

[kwin]

In that case additional (non-default) profiles need to be activated IIUC to load the prerequisites from the right Maven repo: https://github.com/eclipse-platform/eclipse.platform.ui/blob/f5de37a823f637f9e6ea6a56dae9361543dc51c7/pom.xml#L49. That would be crucial to mention. Also I am wondering why that profile is not active by default. IMHO a plain mvn clean verify should always work to ease contributions.

[laeubi]

Please look at maven.config ... the profile IS active by default if you build the repository.... So you probably should describe what issues you see with mvn clean verify ...

[kwin]

My issue was that I have a global corporate mirror in my settings.xml. As said above, this is IMHO still pretty common. Therefore a list of all repository ids which are necessary for the build and not available from Maven Central would be beneficial to mention. There are quite a few though I already painfully collected manually:

1. tycho-snapshots
2. repo.eclipse.org
3. eclipse
4. cbi-jdt
5. cbi-snapshots
6. cbi-releases
7. eclipse-hosted

Those and probably others must never be served from any mirror.

[laeubi]

My issue was that I have a global corporate mirror in my settings.xml

That's for sure something Eclipse platform can't influence.

As said above, this is IMHO still pretty common.

It depends, at laest no one has complained before.

Therefore a list of all repository ids which are necessary for the build and not available from Maven Central would be beneficial to mention.

It might depend on the mirror configuration, but if you think it is useful I don't see why we not could mention it somewhere, I just don't understand how it relates to the topic of aggregator and individual project builds?

You mentioned

Also a pointer towards the SNAPSHOT repository containing the most recent SNAPSHOT builds of the Eclipse dependencies (to not force everyone to build everything oneself) would be helpful

and that's exactly what the individual bundles profile is doing...

There are quite a few though I already painfully collected manually

Maybe they can be unified and maybe maven itself should help the user to get a list of used repositories in case ...

[kwin]

It depends, at laest no one has complained before.

This is (unfortunately) the recommendation of Sonatype for Nexus: https://help.sonatype.com/repomanager3/nexus-repository-administration/formats/maven-repositories#MavenRepositories-ConfiguringApacheMaven

how it relates to the topic of aggregator and individual project builds?

I was initially assuming one needs to build parent locally and that is only available in the aggregator repo.

[laeubi]

I was initially assuming one needs to build parent locally and that is only available in the aggregator repo.

Parent is in snapshot repo and should be activated by the individual bundles profile