How to trigger the extension build step during an hot reload of a non-java resource?

[Mario Fusco]

Hi all,

In Kogito's Quarkus extension we support hot reload of Kogito resources that are non-java files with many different file extensions.

For each of the file extensions recognized by Kogito we have a different compilation provider (for instance this is the one for drools .drl files) that is notified when a file with that extension is modified during an hot reload. At that point the logic contained in the kogito resource is translated into a set of Java sources implementing that business logic and those Java sources are passed to the Quarkus JavaCompilationProvider that is extended by our providers.

That generation of Java sources also triggers the invocation of our build step, but at that point all the work necessary for the hot reload of our stuff has been already done, so what we do is simply an early return from there. Note that in our build step we have (more or less) the same code generation logic that we have in our compilation providers since it has to be executed when the build step is not called during an hot reload.

What I described so far works reasonably well but we are not entirely happy with it because first it obliges us to duplicate the code generation logic, and second it doesn't seem to play well with the bytecode instrumentation introduced with Quarkus 1.11.

That said what we would like to do is keeping our compilation providers only to be notified of the Kogito resources that are changed, but removing from it any code generation logic. At that point we would need to trigger the build step and perform there all necessary code generations as we already normally do outside of an hot reload. Unfortunately there are two issues preventing us to achieve what I described:

1. If we don't take any action in our compilation providers, Quarkus won't invoke our build step. Note that conversely the build step is currently invoked exactly because we perform the code generation in the provider and at that point the build step is useless thus obliging us to execute that early return.
2. There is no way to pass to the build step the list of the changed resource for which the compilation providers have been notified.

I guess that I could workaround 2. writing the names of the changed resources into a temporary textual file and reading that file in the build step, even though this wouldn't be ideal. However problem 1. remains because if I do that, the build step wouldn't be invoked at all.

How can I solve 1., i.e. how can I tell Quarkus when it's time to invoke our build step even if apparently nothing is changed? Do you have any better alternative for 2.?

Any other feedback or suggestion to improve our design is of course very welcome.

Thanks,

Mario

[Georgios Andrianakis]

Hi Mario,

I know that @Michal Szynkiewicz did some work to make the generated GRPC code work properly with hot reload so I am wondering if he thinks it could be applicable in this case as well.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALO%3D_Z61GbxJwuVxrucFJO92ya6iTm-jO93pYWX0BxOkRNu3eQ%40mail.gmail.com.

[Michał Szynkiewicz]

I'm not sure it's the same, I will need to read through Mario's email more carefully after the recharge day ;)

The built-in code generation that is currently used by gRPC (but is designed to be extensible) does the following:

• in a normal maven build, generates java files from some resource files before compilation (and before quarkus-maven-plugin build) and registers the generated files as Maven/Gradle sources
• in dev mode, checks "source resources" for modifications and regenerates java files if found (this is done periodically, not on user's request)

This way we have no code duplication. For gRPC it's all handled by this class [1].

I'd be happy to discuss your use case to see if we can make it work with this mechanism easily. If you'd like that, please ping me on Zulip.

Cheers,

Michał

[1] https://github.com/quarkusio/quarkus/blob/master/extensions/grpc/codegen/src/main/java/io/quarkus/grpc/deployment/GrpcCodeGen.java

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DeAwHEQ1Q3uN0Foot89hgnWuusVm8dZ02d%2BesaPh%2BS6w%40mail.gmail.com.

[Michał Szynkiewicz]

@Mario Fusco, I read your email once again.

It's different from what you describe you'd like but I think moving the logic you have duplicated to the code generator should solve your problem.

Some time ago I added a few details on how it works to KOGITO-2251.

As I wrote before, I'm happy to discuss it on a call.