[OPENJDK-4029] Remove unused maven_init_var_MAVEN_SETTINGS_XML

[jmtd]

This function is also defined in
modules/s2i/bash/artifacts/opt/jboss/container/java/s2i/maven-overrides, and it's that definition which we use in the OpenJDK images.

Note that Wildfly are using the removed definition (in ubi9).

https://issues.redhat.com/browse/OPENJDK-4029

[jerboaa]

Could we fix the test failures first?

Errored scenarios:
  features/jboss.container.java.s2i.bash/files.feature:5  Ensure image scripts are executable (OPENJDK-3935)
  features/jboss.container.maven.s2i/files.feature:5  Ensure save-artifacts script is executable (OPENJDK-3935)

14 features passed, 0 failed, 2 error, 1 skipped

Look like real issues to me.

[jmtd]

Sure, I've only just spotted them. Fix in #609

[jfdenise]

@jmtd ,the file maven-overrides contains multiple generic overrides functions. Some are used by java s2i, some are not but that is the default behavior of the maven.s2i module.
Other s2i modules (such as the java s2i) have the ability to redefine such function in their own override but that is not mandatory.
In a context where openjdk modules are shared with other projects, I would prefer that we keep the existing default s2i behavior and not remove the method.

[jmtd]

Hi @jfdenise , I understand. The issue I have is that at the moment, our team is carrying the cost of keeping the modules working for other products (in fact, only yours I think). OpenJDK moved away from the cct_modules shared module repository because the combination of overhead of using an external module repository, combined with (it felt like) our team taking on the lion's share of the dev work, was unsustainable for us. We have < 1 FTE of resource for the container work, and other, higher priority demands on our time.

I have no problem with us keeping open good lines of communication and giving good notice periods for changes that might disrupt you. And I would like us to at least attempt to avoid causing problems for you where possible.

The move to a new UBI major version is the sole opportunity that we have (since the new images are new, and not upgrades of the existing images) to attempt to control the sprawling complexity of the run scripts, since we do not need to consider theoretical backwards compatibility with customer deployments, and we only get one shot at it every three years.

The overrides scheme makes no sense in the context of a single image. We have three definitions of some functions, of which we use just one, and it's not always clear to me during dev which implementation is relevant. Removing it massively simplifies the run scripts. So I am very much minded to do so, especially since I am not yet aware of a reason you could not move the implementation you use into wildfly-cekit-modules.

I am happy to discuss how we achieve what we want in the least disruptive way to you possible; but I cannot commit to not doing it at all.

[jfdenise]

@jmtd , you convinced me ;-). ubi10 allows for change.
I am thinking that we could align other projects with your behavior. So instead of removing this function in the maven.s2i module, remove it in the java.s2i module and replace the function implementation in the maven.s2i module by the one you are currently using in the java.s2i module.

Doing so all products align on the same overrides (that is already the case except for this function). If we want to change this behavior a project can introduce its own override file.