quarkus-maven-plugin:build keeps stale classloaders

[ppalaga]

As of Quarkus 1.11.0.Final, the build mojo of quarkus-maven-plugin keeps stale class loaders of deployment artifacts built from the same source tree with the same daemon.

Generic steps to reproduce:

1. Find some simple itest in the quarkus, e.g. jsonb
2. Break something in some deployment module used by the test, e.g. fully remove the body of io.quarkus.jsonb.deployment.JsonbProcessor.build(BuildProducer<ReflectiveClassBuildItem>, BuildProducer<NativeImageResourceBundleBuildItem>, BuildProducer<ServiceProviderBuildItem>, BuildProducer<AdditionalBeanBuildItem>, CombinedIndexBuildItem) method.
3. Rebuild quarkus-jsonb-deployment to make sure that it is installed
4. Build the test with a fresh mvnd

   cd integration-tests/jsonb
   mvnd --stop
   mvnd clean verify -Dnative

   The test should fail, because the JsonbProcessor is broken

5. Revert the breakage in io.quarkus.jsonb.deployment.JsonbProcessor.build(BuildProducer<ReflectiveClassBuildItem>, BuildProducer<NativeImageResourceBundleBuildItem>, BuildProducer<ServiceProviderBuildItem>, BuildProducer<AdditionalBeanBuildItem>, CombinedIndexBuildItem) method,
6. Rebuild quarkus-jsonb-deployment with mvnd to make sure that it is installed
7. Rebuild the test project

   cd integration-tests/jsonb
   mvnd --stop
   mvnd clean verify -Dnative

Expected: the test should pass, because the JsonbProcessor is fixed now Actual: the test still fails, because the quarkus-maven-plugin classloader is cached and it contains an outdated version of JsonbProcessor

Workaround: manually kill the daemon when any of the deployment modules was changed.

[gnodet]

@ppalaga you've tested it with the recent changes around the maven caches ?

[ppalaga]

I have tested it with current master. Actually, the steps to reproduce as I have written them above may have other unrelated issues. I have reproduced it camel-quarkus tree, transforming the steps to Quarkus might not be a good idea.

[ppalaga]

quarkus-maven-plugin runs its own instance of aether, and probably keeps its own classloaders independently of Maven caches.

[famod]

@ppalaga So would you suggest to stop using mvnd for Quarkus for now?

What if mvnd had a blacklist of plugins that must not be cached? This might be a workaround for plugins that are known to cause trouble and take some time to be adjusted?

[gnodet]

@ppalaga I can't reproduce with quarkus master and mvnd 0.3.0. The changes seem to be correctly picked up by the daemon when running the test after rebuilding the deployment module.