0

We have a project A that refers a custom parent pom B hosted on our JFROG repository.

When our Github Action is building the project, we are providing a settings.xml file containing the connection to the JFROG repository that allows the action to download the parent pom inside its local repository.

Then a second step of our Github Actions worflow launches a Sonarqube analysis with the maven plugin : mvn org.sonarsource.scanner.maven:sonar-maven-plugin:sonar. This step does not need to download any custom dependencies so we don't provide the settings.xml file but the step fails because maven still tries to download the parent pom from remote repositories (Central) and does not find it.

I can not understand why maven tries to download the parent pom although it has already been downloaded and is available inside the local repository...

We use a Cache action to be sure that the local maven repository is not erased between steps, I checked that the parent pom is well available inside the local repository just before the Sonarqube maven plugin is launched...

I have put Maven in offline mode to force it to use the pom from its local repository but it fails again, it is like Maven was not using this local repository.

I do not think the problem could come from the Github Actions and I do not understand why Maven does not use the local repository...

Matthieu Saleta
  • 1,388
  • 1
  • 11
  • 17
  • I suppose you have two different github actions which are using different docker images in the end. Furthermore to run the scanning of sonar you should using `mvn clean verify sonar:sonar`... If you provide by default a `settings.xml` you should provide the same `settings.xml` for the sonar analysis as well... – khmarbaise Jun 23 '22 at 12:43
  • All the steps are inside the same job and I can see that the parent pom is well available inside the local repository before launching Sonarqube maven plugin. The goal of the job is to build and execute test and optionally to launch Sonarqube analysis, so we have a first step `mvn -s settings.xml verify` and a second one that only launches sonarqube plugin. We do not want to make `mvn verify` twice. – Matthieu Saleta Jun 23 '22 at 12:55
  • why not provide the settings xml to all steps? from my understanding Maven always tries to resolve parents using the repo given in the default Super POM, which is Central. I suspect you provide a `` in your `settings.xml`? – criztovyl Jun 23 '22 at 16:37
  • Please show the github actions definition etc. – khmarbaise Jun 24 '22 at 07:25

2 Answers2

0

In maven settings, there's a separate updatePolicy for releases and snapshots. It's set to daily by default:

  <repositories>
    <repository>
      <releases>
        <updatePolicy>daily</updatePolicy>
      </releases>
      <snapshots>
        <updatePolicy>daily</updatePolicy>
      </snapshots>

So if the files in your local repository are more than a day old, and you don't have a settings.xml, maven will download the dependencies just to be sure.

A workaround would be to provide a settings.xml file with <updatePolicy>never</updatePolicy>

GeertPt
  • 16,398
  • 2
  • 37
  • 61
  • The steps of the Github action are launched one after another so the dependencies are only a few seconds old. But i will try it and make a feedback. – Matthieu Saleta Jun 23 '22 at 12:47
  • I tried this configuration but it didn't work. That was very strange to configure Maven to `never` update from Central Repository. – Matthieu Saleta Jun 23 '22 at 14:33
0

OK I have actually found the reason and it is explained inside this post : maven can't find my local artifacts

To sum up, the pom is downloaded from our JFrog Repository and Maven creates a file _remote.repositories to keep trace of the repository where the dependency comes from.

When the second step executes Maven without the connection to this JFrog Repository, Maven ignores the dependency because it comes from a repository not used by this execution and tries to resolve the dependency again. It is a kind of security feature.

A solution to bypass this feature is to add the property aether.enhancedLocalRepository.trackingFilename with an unknown value : -Daether.enhancedLocalRepository.trackingFilename=some_nonexistent_dummy_file_name.

Matthieu Saleta
  • 1,388
  • 1
  • 11
  • 17