[MSHARED-1147] Inconsistent for settingsFile argument - Maven local repository detecting

[jira-importer]

Slawomir Jaranowski opened MSHARED-1147 and commented

We can provide settingsFile as one of constructor argument.

This value is used only for detecting Maven local repository, not is used as settings for tested Maven project.

Detecting Maven local repository path is done in order by - first wins:

• value in provided by setLocalRepo methods
• value in maven.repo.local system property
• parsing file provided as settingsFile - from constructor argument
• parsing $HOME/{}.m2/settings.xml{} - can be different set by -s options

Proposition

remove this arguments at all, and introduce new system property (like): settings.localRepository

Than we can detect Maven local repository in order by:

• value in provided by setLocalRepo  (by the way we have {}getLocalRepository{})
• value in system property settings.localRepository
• throw exception if not found - we always need this value for rest of methods like get|delete|verifyArtifact..

We can provide settings.localRepository by surefire config:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <systemPropertyVariables>
      <settings.localRepository>${settings.localRepository}</settings.localRepository>
    </systemPropertyVariables>
  </configuration>
</plugin>

With such configuration we always have correct path, not important if

• user provide -Dmaven.repo.local= as Maven build property
• user provide custom settings path by -s

---

Issue Links:

• MSHARED-1414 Verifier.retrieveLocalRepo() does not support interpolation

[jira-importer]

Michael Osipov commented

Interesting... will gladly crunch on this

[jira-importer]

Michael Osipov commented

Stupid question. Why do we need to this as all? I mean if the repo is passed, pass on. If not the called Maven instance can locate the settings itself. Settings can also be passed on als CLI arg.

[jira-importer]

Slawomir Jaranowski commented

a case

• execute build with: -Dmaven.repo.local
• tests not have provided -s custom-settings.xml

then tests will use default user settings and default local repo path, but IMHO should be used provided by -Dmaven.repo.local