Daemon forgets about maven settings on reuse

[Postremus]

I have a custom settings.xml which points to our company nexus.
On first start of the daemon, the settings get applied. Dependencies are downloaded from nexus.

On subsequent uses of the daemon however, the mirrors setting is not getting used. The daemon tries to download from maven central.
I now have to mvnd --stop, and then run the build again.

Log from subsequent runs:

[ERROR] project-web:1.0.0-SNAPSHOT: Unexpected message type 24: ExecutionFailure{projectId='project-web', halted=true, exception='org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project project-web: Could not resolve
 dependencies for project com.company:project-web-1.0.0-SNAPSHOT: com.company:commons:jar:1.1.0 was not found in https://repo.maven.apache.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of central has elapsed or updates are forced'}

Settings.xml:

<mirrors>
		<mirror>
			<id>nexus_internal</id>
			<mirrorOf>internal</mirrorOf>
			<url>https://nexus03.company.com/repository/internal</url>
		</mirror>
		<mirror>
			<id>nexus_public</id>
			<mirrorOf>*</mirrorOf>
			<url>https://nexus03.company.com/repository/public</url>
		</mirror>
	</mirrors>

My mvnd.properties:

maven.settings=/Users/mnp/.m2/mvnd.properties

[Postremus]

mvnd still sometimes downloads from maven central instead of our nexus.

It works fine on a small project (7 modules).
On a larger one with about 49 modules, mvnd downloads dependencies from maven central on the second run.

I run with mvnd clean install -Dmaven.test.skip=true.

mvnd native client 0.7.0-windows-amd64 (0ebc71628ceb3bc37dc1d595fc02daa3e58c820f)
Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal
Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
Maven home: C:\eclipse\tools\java\mvnd\mvn
Java version: 17, vendor: Eclipse Adoptium, runtime: C:\eclipse\tools\java\17
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

[rkraneis]

Same issue here with mvnd 0.6.0; we apply such settings with an activeByDefault profile, which isn't activated ...

[rkraneis]

Unfortunately still happening with

mvnd native client 0.7.0-linux-amd64 (0ebc716)

(But I guess that was to be expected, given the 👍 )

[gnodet]

The 👍 was mainly about the analysis : the fact that an activeByDefault profile isn't activated.
I'll try to replicate the problem in the coming days, but if you have some spare cycles, an integration test would be awesome !

[Postremus]

Can confirm, we also use activeByDefault to activate these settings / add more repositories.

[gnodet]

@rkraneis @Postremus I can't reproduce the problem with activeByDefault profiles. Can you guys set up a reproducer project, maybe using a docker image using xetusoss/archiva or something similar to set up a mirror ? I've tried doing so, but the settings seem to be processed correctly.

[mschorsch]

We also see the issue 0.7.1.

[mschorsch]

The issue seems to happen only in multi module projects.

[cheeghi]

I get the same problem using mvnd 0.7.1-windows-amd64 (on OpenJDK 11) with the Quarkus quickstart project (that produced with the quarkus create command).
The project is not multi-module and it doesn't have activeByDefault profiles.
I tried mvnd on another maven project and it works fine, so it's something project-related.
I tried to reproduce it on Docker (using the openjdk:11 image) without success, but I believe it's always reproducible by bootstrapping the Quarkus quickstart project on a Windows machine.

Anyways, I cloned the project and did some debugging (on the 0.7.1 release commit using the GraalVM 11 jdk), here what I found out:

On the first request (I executed a mvnd clean compile) processed by the daemon the DaemonMavenCli has one ConfigurationProcessor:

While on the second request (another mvnd clean compile), it has two (of the same type actually):

This means that once it enters the configure method (on the second request) it thinks that the user has provided a custom processor and it looks for a processor which isn't a SettingsXmlConfigurationProcessor, but since both of them are, none of the processors get executed:

So, I was wondering why on the second round a new settings processor shows up. I saw that the configurationProcessors map is a EntryMapAdapter returned by the Plexus container and it doesn't allow put operations, so no one in the meantime could have added a new processor in the Map. So I looked into the map's entrySet and I found out that in the end the processors are being saved into a BeanCache field within the LocatedBeans Plexus class. So I think that, at some point, something is updating this cache. It might be something classloader-related, since the two beans seem to come from two different ClassRealms:

Now, I don't have much overview on the project and on Plexus/Sisu, so I don't know if simply removing duplicate processors from the Map could be the right solution, or if this is a sign of a "broader" problem (maybe of how classes are being loaded).

I hope this gives some more info on the problem.

Edit: I attach the quarkus quickstart project so it's not necessary to have quarkus installed.

[pptom]

I get the same problem using mvnd-0.7.1-linux-amd64

[Min-200]

Has this problem been solved? I am 0.9.0 and still have qualified extra puzzles

[gnodet]

A PR with an integration test would be really nice to diagnose / debug this issue...

[Min-200]

I am a multi-module project, the same code, in the same daemon process, first compiled the first time can work, the second compilation error, error content for the submodule can not find the version number in the parent pom

[gnodet]

@Min-200 Can you provide a simple reproducer project with basic instructions ?

[Min-200]

Is there a parameter that will allow me to stop the daemon if the mvnd build fails

[ppalaga]

Is there a parameter that will allow me to stop the daemon if the mvnd build fails

no

[gnodet]

Is there a parameter that will allow me to stop the daemon if the mvnd build fails

no

That's somewhat related to #374.