I would like to specify my maven settings once for all my maven workspaces

[l0rd]

Is your enhancement related to a problem? Please describe.

Currently I need to create a new maven settings.xml file for every new workspace I create. When #14680 will be implemented it will be possible to specify settings.xml as a secret and get it automatically mounted in my maven workspaces.

Describe the solution you'd like

Update maven settings documentation after #14680 has been solved.

[skabashnyuk]

This issue partially overlap with #14680
They have a common part: the user should be able to configure secrets/configmap in his k8s namespace.
After that #14680 is about to mount these secrets as environment variables and #16857 is about to mount them as a file? @l0rd have you think about UX of this process. For example: what happens if the user trying to create a workspace with such a devfile but no secrets/configmap exist in his k8s namespace?
how do you see these elements should be mounted in devfile?

[l0rd]

This is a documentation issue. #14680 describes the technical feature that will allow to automatically mounts selected secrets in Che workspaces. This is about documenting about how this feature can be used to configure maven settings in workspaces.

[sparkoo]

The difficulty here is that in our samples, we're using m2 volume at /home/user/.m2 (https://github.com/eclipse/che-devfile-registry/blob/master/devfiles/java-maven/devfile.yaml#L40). The maven needs settings.xml to be placed at /home/user/.m2/settings.xml. Then when we try to mount secret there with che.eclipse.org/mount-path: /home/user/.m2, we fail on check of uniques of volume paths (https://github.com/eclipse/che/blob/master/infrastructures/kubernetes/src/main/java/org/eclipse/che/workspace/infrastructure/kubernetes/provision/SecretAsContainerResourceProvisioner.java#L166). This limitation exists, because kubernetes can't mount multiple volumes into same path.

Considering we don't want to change Che-server code, I see following options:

• if we set /home/user/.m2/repository as a volume in the devfile, it's possible to have secret that contains settings.xml with che.eclipse.org/mount-path: /home/user/.m2.
  • for existing workspaces, when we change /home/user/.m2 into /home/user/.m2/repostiory, already existing maven artifacts now will be mounted into /home/user/.m2/repository/repository. So we would need to clearly document this if we decide to suggest this way.
  • It won't be longer possible to create settings.xml manually, because /home/user/.m2 won't be persisted like this.
  • if we want to have this option by default, we would need to change all our maven sample devfiles
• we can suggest to mount settings.xml anywhere else (e.g. /tmp/maven-settings/settings.xml) and then I see 2 options (this is all manual actions that has to be done by user):
  • create command to copy it into /home/user/.m2/settings.xml. User then would have to run it at least once after first workspace run. Then it will be persisted as part of .m2 directory, so it will be needed to run it only in case of update.
  • update all maven tasks to define -s /tmp/maven-settings/settings.xml, that tells maven to use settings.xml on custom path.

Or we can fix the issue properly, which would need changes in Che-server code. We're thinking about something like mount the secrets some common place (e.g. /tmp/secret-mounts), then copy them to their places in initContainer. With this, we would enable to mount secrets as individual files anywhere we need, without kubernetes limitations.

Question is, are we ok with documenting workaround in this not ideal state? Or do we want to have it properly working now, fix it and do async release?

cc: @l0rd @skabashnyuk @mshaposhnik @metlos

[skabashnyuk]

Question is, are we ok with documenting workaround in this not ideal state?

Yes. I think we should document current behavior and the way how to workaround possible issues.

Or do we want to have it properly working now, fix it and do async release?

Yes. Let's start thinking about how to do that in a more optimal way to provide better UX.

[l0rd]

@sparkoo what about documenting to mount settings.xml into ${maven.home}/config rather than ${home}/.m2?

For proper solution we can look at how projected volumes work (design doc).

[skabashnyuk]

@sparkoo what about documenting to mount settings.xml into ${maven.home}/config rather than ${home}/.m2?

I think the biggest problem is that we don't know where ${maven.home} is pointing before we start the workspace.

[sparkoo]

@sparkoo what about documenting to mount settings.xml into ${maven.home}/config rather than ${home}/.m2?

For proper solution we can look at how projected volumes work (design doc).

${maven.home}/conf contains multiple config files, not only settings.xml.

[l0rd]

I think the biggest problem is that we don't know where ${maven.home} is pointing before we start the workspace.

@skabashnyuk right and that's why it's not the ideal solution. But the user that owns the devfile should know where the ${maven.home} is so he should be able to configure the path in the secret or the devfile.

${maven.home}/conf contains multiple config files, not only settings.xml.

@sparkoo when this is the case that folder cannot be used, I agree.

[sparkoo]

fixed by eclipse-che/che-docs#1302