quarkus-maven-plugin:build keeps stale classloaders
See original GitHub issueAs 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:
- Find some simple itest in the quarkus, e.g. jsonb
- 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. - Rebuild
quarkus-jsonb-deployment
to make sure that it is installed - 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.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:5 (5 by maintainers)
@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?@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.