feat(workers): Include GradleDefinitions in the GradleInitGenerator

[bs-ondem]

Extend the GradleInitGenerator to include repositories from GradleDefinitions in addition to the globally configured MavenCentralMirror. Override the globally configured MavenCentralMirror if a GradleDefinition uses the same URL.

[sschuberth]

How about beautifying this with the

"""
...
""".trimIndent()

approach?

[sschuberth]

FYI, I've done this now also for existing code in #3153.

[bs-ondem]

@sschuberth we at Bosch are currently unsure whether the new feature (allowing GradleDefinitions to be configured in the .ort.env.yml file to override the globally configured MavenCentralMirror or to add private repositories) is actually needed by our customers.
The Maven rate-limit issue is already addressed by the previous PR that writes the global MavenCentralMirror into the init.gradle.kts file. For private repositories, our customers can already configure them directly in their build.gradle(.kts) files and provide the required credentials via environmentVariables, so that the repositories can be resolved as needed. Do you see any need or benefit for supporting configuration of GradleDefinitions via .ort.env.yml from Double Open point of view? Or more generally, are there use cases where it makes sense to configure repositories in the init.gradle.kts file rather than build.gradle(.kts)? For example, in situations where developers use private company repositories/mirrors that cannot be included in the open source project’s build.gradle(.kts) file, so they keep such configuration in init.gradle.kts.

[sschuberth]

Or more generally, are there use cases where it makes sense to configure repositories in the init.gradle.kts file rather than build.gradle(.kts)?

I guess this boils down to the old question of self-contained builds vs. central configuration, which means there's no clear answer. Personally, I'm pro self-contained builds, even if that might require some repetition of global configuration in some cases.

So I'd proceed as I always try in such cases: Keep it simple unless the added complexity is clearly needed.

[mnonnenmacher]

@eclipse-apoapsis/bosch Are there any plans to continue working on this?