-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Quarkus 1.8.1.Final + infinispan-client and deletion of Marshaller.class files #9980
Comments
Update: I added maven profiles to facilitate testing in Quarkus 1.4.2.Final and Quarkus 1.3.4.Final as well. They all exhibit this behavior, so this isn't a regression.
|
FYI, our only way to work around this is with the Deprecated MessageMarshaller<> |
It sounds like the annotation processor is not being ran for some reason when |
Using inotifywait I can see the AP is properly invoked initially and generates the classes, but then they are all removed and recompiled again but the second time the AP is not invoked it seems
I removed
from the pom.xml and now it works for me. |
Thanks for looking into this @wburns The reproducer is a project generated from code.quarkus.io, which includes the maven-compiler-plugin block. Is investigation still ongoing or is the recommended fix to remove the maven-compiler-plugin block to resolve? If the recommended fix is to remove the maven-compiler-plugin block, is the generator at code.quarkus.io going to be updated appropriately? |
Unfortunately, I am not a maven wiz and Quarkus does their own pom magic in their plugin. So my guess is the example should probably be changed. WDYT @gsmet ? |
The maven-compiler-plugin configuration is where compiler arguments are currently specified for maven projects. I guess what I'm trying to say, poorly, is that maven-compiler-plugin is the idiomatic way to configure any compiler arguments within maven projects. I would personally recommend figuring out what is causing this problem and resolving it, rather than requiring removal of a pretty standard Maven configuration. It will affect multi-module setups where quarkus is but one component, or where companies have a master parent pom that configures all their best practices. |
I just discovered that this problem does NOT exhibit itself when maven-compiler-plugin 3.8.0 is used. Nothing in the release notes to go on, though: https://blogs.apache.org/maven/entry/apache-maven-compiler-plugin-version1 |
So it breaks with |
Correct. |
That sounds like a maven compiler plugin |
If it is a bug in maven-compiler-plugin, regardless, the reproducer project was generated from code.quarkus.io, which sets maven-compiler-plugin version to 3.8.1. Thus this should affect anyone using Infinispan who have recently generated a project and followed the Infinispan guide. It's also possible that the maven-compiler-plugin version upgrade surfaced some race condition in the quarkus plugin that is otherwise hidden. I don't know anything about the internals of the quarkus-plugin, the quarkus annotation processor that was mentioned in a comment in this issue, and how they tie into the maven lifecycle methods to know where to start looking. With Maven-compiler-plugin 3.8.1 (the version that code.quarkus.io uses in its generated projects):
while
Is it reasonable to expect that a project generated from code.quarkus.io, and modified following a quarkus guide, would function without error? If so, then this issue should be addressed in some manner within the quarkus ecosystem, as currently that expectation is not met based on this reproducer. From @wburns investigation and suggestion, there does appear to be a behavior change based on whether maven-compiler-plugin is included in the pom or not. |
@sean-scott-lr do you reproduce these issues with the latest stable Quarkus that is built with the latest Infinispan? |
Yes |
Also, I Looked into just not using the auto generated protostream method since it doesn't work in quarkus, and directly writing a Marshaller however this method has been deprecated for quite a while by protostream and will be removed soon. ( protostream 4.4 ). |
@sean-scott-lr I will work on your reproducer now but it seems very odd. I could not reproduce this issue in my demo |
@sean-scott-lr Just to clarify, the auto generated protostream method does work in Quarkus. What it is failing here is something else. I've tested your example and indeed I can reproduce the problem when we specifically run 'mvn clean compile test' on a row. Could you please tell me if 'mvn clean test', 'mvn clean package' and 'mvn clean install' do also work for you? In any case this error is odd and I will report it to our protostream main maintainer in the team in case there is something missing from our side when we specifically call 'mvn clean compile test'. |
No running the maven goals one at a time does not work for us. I believe that this issue is just being surfaced a particular way in the reproducer on this ticket ( by running more than a single goal at the same time ). I believe that since we have a multi-module maven project, the same problem is being surfaced even when running a single goal. In our multi-module project, here are the adapted steps from above: Execute ./mvnw clean
Execute ./mvnw compile
Execute find target -name 'Marshaller' and see that the java files and class files exist
Execute ./mvnw test and see the test pass
Interestingly running this again:
|
Title, description and reproducer repo updated. Problem still exists in Quarkus 1.8.1.Final. In the project that drove the creation of this issue and reproducer, a simple |
@jeffhubLR thanks for the clarifications! As I mentioned before, the team will check if this is a protostream issue and if something was missing or if it's a maven bug we need to report. |
I have reproduced the problem in a simpler project that doesn't use Quarkus. After debugging it I'd say it's an aggregate of a maven-core problem (or tradition?), a maven-compiler-plugin problem introduced in 3.8.1, and a protostream problem.
IMO issue # 1 is just the way Maven works, and it's not going to change any time soon. Because of this, I not suggest using more than one phase from each lifecycle on the Maven command line. |
Thank you very much for the thorough analysis, explanation and writeup, @danberindei . When you create the issue in the maven-compiler-plugin JIRA, would you mind posting that here so I can watch its progress? |
#3 is fixed (worked around) by https://issues.redhat.com/browse/IPROTO-161 "Enhance generated source file up-to-date check by also ensuring the class file exists and is newer than the java file" This is released in protostream 4.3.4.Final and @danberindei 's simple reproducer without Quarkus (https://github.com/danberindei/maven-compiler-test/tree/master) confirms the fix. It would be great to have confirmation of how it behaves in quarkus. |
@jeffhubLR the maven-compiler-plugin issue is https://issues.apache.org/jira/browse/MCOMPILER-433 |
@anistor @danberindei I've also verified that updating to protostream 4.3.4.Final (and going back to the current default of maven-compiler-plugin: 3.8.1) corrects the problem in our multi-module monorepo with multiple quarkus services and a shared library. Once that, or another fix, is incorporated into Quarkus, this can be closed. |
@jeffhubLR We are about to release 11.0.4.Final that includes this fix, we will upgrade Quarkus to that version after. Thanks! |
@karesti when do you plan to update Quarkus? I'm releasing 1.9.0.CR1 tomorrow morning. |
@gsmet I will get a PR ready today. |
Describe the bug
With a clean project generated from https://code.quarkus.io/ and following the Infinispan guide (https://quarkus.io/guides/infinispan-client), namely the Annotation based serialization (https://quarkus.io/guides/infinispan-client#annotation-based-serialization), there are scenarios where the generated Marshaller java files are not compiled into class files (or they are, but then removed), resulting in the following error:
Expected behavior
Regardless of
mvn
command used, the class files should be reliably generated which would prevent the above error.Actual behavior
If
./mvnw clean compile test
is executed, no class file is compiled for the generated Marshaller sources, resulting in the above error. **NOTE THAT THIS IS JUST A SIMPLE REPRODUCTION, IN PRACTICE THIS BEHAVIOR IS WITNESSED WITH A SIMPLEmvn compile quarkus:dev...
To Reproduce
Steps to reproduce the behavior:
./mvnw clean compile test
and observe the errorfind target -name '*Marshaller*'
and see that the java files exist, but no class filesNow to see it work, do the following:
./mvnw clean
./mvnw compile
find target -name '*Marshaller*'
and see that the java files and class files exist./mvnw test
and see the test passConfiguration
Environment (please complete the following information):
uname -a
orver
: Darwin USMACEA094JHUBB 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64java -version
:openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
mvnw --version
orgradlew --version
): ./mvnw --versionApache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /Users/jeff.hubbach/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3
Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.15.4", arch: "x86_64", family: "mac"
The text was updated successfully, but these errors were encountered: