4

I have several projects which point to different internal repositories. Users on one project might not be able to see the repository on the other project, so I need a project specific settings.xml for each project.

Create project-specific Maven settings indicates that I can do this by creating a MVN_ROOT/.mvn/maven.config with

--settings ./.mvn/settings.xml

and then putting the repository information inside MVN_ROOT/.mvn/settings.xml.

That seems to work and I can add those files to git and other users can use the repository automatically.

However, the repositories require validation, which requires that settings.xml contain something like

...
<server>
  <id>repo-proj-1</id>
  <username>me</username>
  <password>secret</password>
</server>
<server>
  <id>repo-proj-2</id>
  <username>my.name</username>
  <password>secure</password>
</server>
...

Obviously, I do not want to put this information into the git repository. ~/.m2/settings.xml is the obvious place to put that information. However, it appears that I can only have one user settings file, as my login information is not picked up when I try to build.

Is there a way to use both settings files?

This needs to work on Mac, Linux and Windows, so something like <xs:include>~/.m2/settings.xml</xs:include> (XML include, probably not the right syntax) won't work as ~/.m2 is not usually the right location on Windows.

We are using Maven 3, and if a specific recent version is required, we can require users to upgrade to that version.

Troy Daniels
  • 3,270
  • 2
  • 25
  • 57

2 Answers2

1

What about to treat the secrets as environment variables? 

<server>
  <id>repo-proj-2</id>
  <username>${user}</username>
  <password>${pass}</password>
</server>

You can set them then via your build tool:

mvn -s ./build/settings.xml -Duser=xxx -Dpass=xxx clean install
ttulka
  • 10,309
  • 7
  • 41
  • 52
  • Depending on shell settings, this leaves passwords in command history which can be persisted to disk unencrypted. – user944849 Mar 12 '19 at 17:35
  • @user944849 the build machine must know the password anyway, even when encrypted, the master password must be given. It depends on the tool. We're using docker images for a pipeline run, the instance is destroyed after the build process finishes. – ttulka Mar 12 '19 at 17:49
  • destroying the instance ensures the passwords are not persisted. A naive approach could leave the passwords unprotected, and my comment was merely encouraging folks to consider this. – user944849 Mar 12 '19 at 17:54
  • If the variables are `PROJ-2.USER` and similar, then they can be set in `.bashrc` (or some file sourced by that), which seems to be almost as secure as storing them in `.m2/settings.xml`. (If some one can see my environment variables, then they can probably also see the files on my system.). – Troy Daniels Mar 12 '19 at 21:13
1

There should be a central repository which contains SNAPSHOT's and an other one which contains releases and a group in a repository manager which combines them for consuming. This should be configured in a settings.xml located either in Users home directory or in the configuration of your CI server.

Deployment to repositories should only being done by a CI Server never by a developer.

In the CI server you should correctly setup the credentials to be hosted by the CI Server (Jenkins: Credentials Store) etc.

If you need separate settings.xml by project it is a design problem in your setup's...and will cause many issues.

The separation of different projects is a basic thing in a Maven repository which is called coordinate which is a combination of groupId and artifactId plus version.

In general a settings.xml should be located only in the users home directory which contains users credentials if needed (as already mentioned combined with encryption).

khmarbaise
  • 92,914
  • 28
  • 189
  • 235