[GitHub] [maven-mvnd] cheeghi edited a comment on issue #490: Daemon forgets about maven settings on reuse
cheeghi edited a comment on issue #490: URL: https://github.com/apache/maven-mvnd/issues/490#issuecomment-1000918798 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](https://quarkus.io/get-started/) 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](https://github.com/apache/maven-mvnd/blob/97c587c11383a67b5bd0ff8388bd94c694b91c1e/daemon/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L238) 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](https://github.com/apache/maven-mvnd/blob/97c587c11383a67b5bd0ff8388bd94c694b91c1e/daemon/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L1039) 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](https://github.com/apache/maven-mvnd/blob/97c587c11383a67b5bd0ff8388bd94c694b91c1e/daemon/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L183) 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](https://github.com/apache/maven-mvnd/files/7775066/code-with-quarkus.zip) so it's not necessary to have quarkus installed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] cheeghi edited a comment on issue #490: Daemon forgets about maven settings on reuse
cheeghi edited a comment on issue #490: URL: https://github.com/apache/maven-mvnd/issues/490#issuecomment-1000918798 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](https://quarkus.io/get-started/) 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](https://github.com/apache/maven-mvnd/blob/97c587c11383a67b5bd0ff8388bd94c694b91c1e/daemon/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L238) 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](https://github.com/apache/maven-mvnd/blob/97c587c11383a67b5bd0ff8388bd94c694b91c1e/daemon/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L1039) 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](https://github.com/apache/maven-mvnd/blob/97c587c11383a67b5bd0ff8388bd94c694b91c1e/daemon/src/main/java/org/apache/maven/cli/DaemonMavenCli.java#L183) 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
