-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate and fix kogito-maven-plugin usage inside kogito-runtimes project itself #1460
Investigate and fix kogito-maven-plugin usage inside kogito-runtimes project itself #1460
Comments
After first iteration, it turns out that the root cause of that "workaround" is the usage of reflection on generated classes to code-gen other classes (see here) |
If I recall correctly, this reflection is not performed over generated classes, but performed on user provided classes to generate the bridge to call them. |
@fjtirado the problem lies when you have a service task (pojo) defined in the src where the plugin is being executed. In those cases the codegen cannot find it. (as generate-sources) it is executed before the compilation hence the problem with the lifecycle we had. You have an example of this in here: |
@elguardian yes, Im skeptical about the possibility of removing such reflection. We need to analyze the classes on src to be able to generate proper code to call them |
@fjtirado Yeah.. it is not possible to remove the reflections. So what I pointed out is to fix the use case mentioned above. |
@elguardian Yes, I misunderstood @gitgabrio I read "over" generated classes, when he wrote "on", probably it should have been "in" (communication in non native language is a ...) |
Other cases we have are just for quarkus (OpenApi for sonataflow) and we are using Jandex to introspect the user class. |
@elguardian @fjtirado I updated my comment. |
@elguardian @fjtirado
To recap, I think we can't escape from "pre-compile" (as happen in the kie-maven-plugin) but we can provide that code-generation happen only once soon after, and that later only newly code-generated sources will be compiled/dumped. I add @mariofusco to also have his opinion on that, especially about the rule part |
kogito-maven-plugin is used to build springboot-based kogito projects.
It contains three mojos and a couple of configurations to drive maven life-cycle.
With that in place, its usage requires the
<extensions>true</extensions>
flag (see documentation)The problem with this approach is that if another module, inside kogito-runtimes, need it, the mvn reactor tries to resolve it during initial pom parsing and, since the plugin has not been built, yet, the initial pom parsing fails.
This became evident after refactoring of springboot integration tests, that relies on it.
The issue is also hidden in our CI for some unclear reason, when using the usual "999-SNAPSHOT" version, but it become evident when the version is changed.
The most straightful solution would be to rewrite/modify the plugin to not depend on its customized lifecycle, so that it can be used without the
<extensions>true</extensions>
flag, but there could be other problems, so this need investigation.As further indication, here's the execution order with
<extensions>true</extensions>
flag:and this is with
<extensions>false</extensions>
flag:@baldimir @elguardian @fjtirado @porcelli
The text was updated successfully, but these errors were encountered: