Quarkus: Quarkus quarkusDev mode not working in a gradle multimodule project - but the runable jar does.

[marcelhanser]

Describe the bug
I have following modules in my gradle project:

• common (common stuff, just jee-spec dependencies)
• common-integration (implementations for stuff in common, quarkus dependencies (incl. plugin))
• domain (domain stuff uses interfaces of common, just jee-spec dependencies)
• domain-integration (quarkus dependencies (incl. plugin), generates the final deployable)

Thats the dependency structure:
domain -> common
common-integration -> common
domain-integration -> domain
domain-integration -> common-integration

Every module contains META-INF/beans.xml file ins src/main/resources

Expected behavior
domain-integration:quarkusDev should start as the runnable jar does.

Actual behavior
It doesnt.
The gradle command: domain-integration:quarkusDev complains during startup that some beans implemented in common-integration cannot be resolved. While domain-integration:quarkusBuild doesnt show any issue and the resulting runnable jar also works as expected.
It seems like, that the annotations of the direct project compile dependencies are not processed in quarkusDev mode. Also i experienced that if i add the domain-integration -> domain dependency quarkusDev mode fails with the not indexed entities issue - therefore i guess that the beans.xml & jandex indexes and are not discovered.

To Reproduce
Steps to reproduce the behavior:
The structure above is a subset of the modules of our project. I did not create a reduced project yet
gradle-files.txt

1. Create the module structure above
2. See the attached files for examples
3. Try quarkusDev and quarkusBuild

Environment (please complete the following information):

• Output of uname -a or ver:
  Microsoft Windows [Version 6.1.7601]
• Output of java -version: openjdk 11 2018-09-25
  OpenJDK Runtime Environment 18.9 (build 11+28)
  OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
• GraalVM version (if different from Java): not used
• Quarkus version & plugin version: 1.2.1.Final
• Build tool (ie. output of mvnw --version or gradlew --version):
  Gradle 5.6.4

Additional context
(Add any other context about the problem here.)

[quarkusbot]

/cc @quarkusio/devtools

[gastaldi]

@marcelhanser can you try it with 1.3.0.CR1 or the latest master (999-SNAPSHOT)?

[gastaldi]

This looks similar to https://github.com/quarkusio/quarkus/issues/6561

[marcelhanser]

@gastaldi just checked with 1.3.0.CR1
Now i get tones of javax.enterprise.inject.AmbiguousResolutionException's during startup. Seems like every bean is twice in the container.

[andreas-eberle]

I see the same issue with the AmbigousResolutionExceptions in my project. This also happens with version 1.3.0.CR2.

[aloubyansky]

Thanks for reporting the issue. Just in case you guys can create a simple reproducer, the chance of getting this fixed for 1.3.0.Final will be higher.

[marcelhanser]

Allright - did that:)
You can clone it from here
https://github.com/marcelhanser/quarkus-playground
Setup is as described and it shows the described behaviour.
gradlew domain-integration:quarkusDevfails depending on the version:

• 1.2.1.Final: javax.enterprise.inject.UnsatisfiedResolutionException
• 1.3.0.CR2: javax.enterprise.inject.AmbiguousResolutionException

But the resulting build artifact works fine

[aloubyansky]

Thanks a lot for the reproducer @marcelhanser. I fixed a few issues using it, specifically https://github.com/quarkusio/quarkus/pull/7816 and https://github.com/quarkusio/quarkus/pull/7820 but unfortunately, it appears it's not enough and I won't have time to figure it all out before the release. Sorry about that.

[killboard]

I'm using the quarkus version 1.2.1.Final and is occurring this issue too.

I have a module with quarkus using other module with plain kotlin and with gradlew quarkusDev throws exception:

 Task :gateway-core:compileKotlin UP-TO-DATE
> Task :gateway-core:compileJava NO-SOURCE
> Task :gateway-core:processResources UP-TO-DATE
> Task :gateway-core:classes UP-TO-DATE
> Task :gateway-core:inspectClassesForKotlinIC UP-TO-DATE
> Task :gateway-core:jar UP-TO-DATE
> Task :gateway-application:compileKotlin NO-SOURCE
> Task :gateway-application:compileJava NO-SOURCE
> Task :gateway-application:processResources UP-TO-DATE
> Task :gateway-application:classes UP-TO-DATE
Listening for transport dt_socket at address: 5005
Exception in thread "main" java.lang.RuntimeException: java.nio.file.NoSuchFileException: /home/killboard/Dropbox/MovilePay/Projects/movilepay-fraud-gateway/gateway-core/src/main/java
        at io.quarkus.dev.DevModeMain.main(DevModeMain.java:71)
Caused by: java.nio.file.NoSuchFileException: /home/killboard/Dropbox/MovilePay/Projects/movilepay-fraud-gateway/gateway-core/src/main/java
        at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
        at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
        at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
        at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
        at java.nio.file.Files.readAttributes(Files.java:1737)
        at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
        at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
        at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
        at java.nio.file.FileTreeIterator.<init>(FileTreeIterator.java:72)
        at java.nio.file.Files.walk(Files.java:3574)
        at java.nio.file.Files.walk(Files.java:3625)
        at io.quarkus.dev.RuntimeUpdatesProcessor.checkForChangedClasses(RuntimeUpdatesProcessor.java:173)
        at io.quarkus.dev.DevModeMain.start(DevModeMain.java:92)
        at io.quarkus.dev.DevModeMain.main(DevModeMain.java:67)
> Task :gateway-application:quarkusDev

BUILD SUCCESSFUL in 2s

[aloubyansky]

@killboard looks like a different issue than what's been originally reported here. Do you mind creating a new one? Thanks.

[aloubyansky]

@marcelhanser @andreas-eberle I know what the issue is and even with some hacking made it work locally. Besides the issues I've already fixed (mentioned above), it's related to the local project deps being resolved as JARs instead of dirs of classes.

[killboard]

@aloubyansky issue created, I discovered a workaround to make the things works but is a very ugly, I described the steps in the issue. Thanks
https://github.com/quarkusio/quarkus/issues/7832

[marcelhanser]

@aloubyansky. Sounds quite promising :) Do you already know the planned milestone for the fix? We would really like to switch to quarkus, but this one is blocking us to do so.

[aloubyansky]

If it's not 1.3.1.Final it should be 1.4.0.Final. There are a few other Gradle issues that I want to address. This one is definitely one of the most critical ones.

[marcelhanser]

Very cool! Thank you guys. Another small somehow related question: Will the quarkusDev mode in 1.4.0.Final also listen to source changes in all referenced project dependencies`?

[aloubyansky]

@marcelhanser have you tried 1.3.0.Final? I encourage you to give it a try and create issues for something that does not work. Thanks a lot!