Regression in 1.7: Dev mode auto-compile fails in MapStruct with "Attempt to recreate a file for type ..."

[famod]

Describe the bug
I am getting this strange error during auto-compile while trying to start dev mode in one of our modules:

[INFO] --- quarkus-maven-plugin:1.7.0.CR2:dev (default-cli) @ middleware-patient-api-pro-fe ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 54 source files to C:\Develop\someproject\middleware\_develop-2\someproject-middleware\patient\api\pro-fe\target\classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /C:/Develop/someproject/middleware/_develop-2/someproject-middleware/patient/api/pro-fe/src/main/java/com/somecompany/someproject/middleware/patient/api/pro_fe/data/mapper/CaseFileApiMapper.java:[26,8] Internal error in the mapping processor: java.lang.Rat org.codehaus.plexus.classworlds.launcat org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)  Caused by: javax.annotation.processing.FilerException: Attempt to recreate a file for type com.somecompany.someproject.middleware.patient.api.pro_fe... 49 more  Casat jdk.compiler/com.sun.tools.javac.processing.JavacFiler.createSourceFile(JavacFiler.java:426)  stence(at org.mapstruct.ap.internal.processor.MapperRenderingProcessor.createSourceFile(Mappe[INFO] 1 error

I have no clue why this is so horribly garbled. mvn -e ... doesn't help much but at least reveals which type was attempted to recreate.

Attempt to recreate a file for type com.somecompany.someproject.middleware.patient.api.pro_fe.data.mapper.CaseFileApiMapperImpl
    at org.mapstruct.ap.internal.processor.MapperRen(... garbled, I suppose MapperRenderingProcessor)

This is not flaky, btw. Only the affected "MapperImpl" can fluctuate (we have multiple mappers).

Dev mode in another module does work, but there we do not use MapStruct.

The very same code works with 1.6.1.Final!

Expected behavior
Should just compile (if needed) without errors.

Actual behavior
Build is aborted.

To Reproduce
Steps to reproduce the behavior:

1. git clone clone https://github.com/famod/quarkus-quickstarts
2. git switch issue-11253-mapstruct-vs-prepare
3. cd getting-started
4. should pass: mvn clean verify (or install)
5. should fail: mvn quarkus:dev

Note: This reproducer uses MapStruct 1.4.0.Beta3. Downgrading to 1.3.1.Final does not change anything.

Configuration
n/a

Environment (please complete the following information):

• Output of uname -a or ver: MINGW64_NT-10.0-18363 XXX 3.0.7-338.x86_64 2019-11-21 23:07 UTC x86_64 Msys
• Output of java -version: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)
• GraalVM version (if different from Java): n/a
• Quarkus version or git rev: 1.7.0.CR1 or 1.7.0.CR2
• Build tool (ie. output of mvnw --version or gradlew --version): Apache Maven 3.6.3

Additional context
mvn clean compile quarkus:dev works, which is no wonder since compile is skipped in this case.

I found two commits that may have something to do with it (the first one being the "hottest" candidate):

• 93e1ba6#diff-c007939524ea2a3177991ef913abf5df
• 3d7e642#diff-c007939524ea2a3177991ef913abf5df

I did not yet have the time to debug this.

[famod]

@michalszynkiewicz Could it be caused by the new prepare execution?

[michalszynkiewicz]

@famod I don't think it's likely. prepare happens earlier and should have no impact on compilation.

[famod]

@michalszynkiewicz Well...prepare is causing this problem, somehow.

The problem vanishes once I switch this to false in the debugger: https://github.com/quarkusio/quarkus/blob/1.7.0.CR2/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java#L387

The number of sources being compiled is then also much lower than with the auto-prepare.

[famod]

Btw, explicit mvn quarkus:prepare quarkus:dev doesn't help.

[famod]

@aloubyansky Do you have a clue what's going on?
I'll compare target for both cases (ok/not ok).

[aloubyansky]

Not yet. One thing with code get is that it does not seem to take into account the launch mode. But it's unlikely the cause here.

[famod]

So the workaround for now is -Dquarkus.prepare.skip (or set via pom.xml).

I don't really understand why this new goal is kicked off by default. Shouldn't there be an opt-in instead?

PS:

I'll compare target for both cases (ok/not ok).

Well, no relevant difference AFAICS.

[michalszynkiewicz]

Thanknyou for investigating it @famod! Do you happen to have some small reproducer?

[famod]

Do you happen to have some small reproducer?

No, unfortunately I don't. I am not allowed to share the affected project so I'd need to create a reproducer from scratch,
But after all this might be easier than I first thought. Still, please don't expect any reproducer from me in the next few days because I am busy with other Quarkus issues and PTO stuff. 😉

[michalszynkiewicz]

If I have time, I'll try to create a reproducer. But I don't know mapstruct, also have other important stuff and start PTO next week ;)

Anyway, good to know that it's the prepare goal that causes the problem.

[famod]

I have a reproducer ready locally. Will push it to GH later today or tomorrow.

[famod]

Reproducer is up! See updated issue description.

Edit: Added a missing step (cd getting-started).

[gsmet]

@aloubyansky @michalszynkiewicz I let you have a look at the reproducer?

[famod]

FWIW, I am almost certain that the problem is caused by CodeGenMojo more or less blindly adding generated-sources source root, which already exists due to the MapStruct generation:

• https://github.com/quarkusio/quarkus/blob/master/devtools/maven/src/main/java/io/quarkus/maven/CodeGenMojo.java#L105-L109
• https://github.com/quarkusio/quarkus/blob/master/devtools/maven/src/main/java/io/quarkus/maven/CodeGenMojo.java#L62

My theory is that then generated-sources is processed twice, but I might have missed something.

At this point I'd (again) strongly suggest to also bypass auto-code-gen in DevMojo in case it makes no sense to invoke it in the first place (e.g. when there are no .proto files).

[gastaldi]

@famod if you run with mvn compile quarkus:dev it should work. I think the problem is here:

quarkus/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java

Lines 271 to 273 in 1d754b2

	//we always want to compile if needed, so if it is run from the parent it will compile dependent projects
	handleAutoCompile();

[famod]

@gastaldi

@famod if you run with mvn compile quarkus:dev it should work.

Yeah, I know that it can be mitigated by specifying compile explicitly (see "Additional context").
But since that works without a problem in 1.6.1.Final and before, the new prepare goal is most likely the culprit (AFAICS).

[gastaldi]

Perhaps one solution would be to run clean compile instead of just compileor simply nuking generated-sources before invoking the compile mojo

[gastaldi]

I opened #11311 which seems to fix the issue, let me know if there is a case where this wouldn't work

[arunkjn]

Hi, I am facing the same issue in quarkus 2.3.0.FInal and also 2.2.3.Final

[aloubyansky]

@arunkjn please open a new issue and describe your issue in detail. A reproducer will help a lot. Thanks!