quarkus:dev finds duplicate beans if a different version of the dependency is in the maven reactor

[stephenc]

Describe the bug

This was discovered while using a "local aggregator" pom to make importing a group of related projects into the IDE easier.

We have a group of related mukti-module projects: let's call them common-lib, openwebbeans-app and quarkus-app.

All these projects are in separate git repositories.

Some developers like to checkout each project in its own IDE window.

Others like me create a "local aggregator" that throws them all together in the same IDE, e.g.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>localdomain.localhost</groupId>
  <artifactId>localhost-aggregator</artifactId>
  <version>1.x-SNAPSHOT</version>
  <packaging>pom</packaging>

  <modules>
  	<module>common-lib</module>
  	<module>openwebbeans-app</module>
  	<module>quarkus-app</module>
  </modules>
</project>

The check-out version of all our projects is always 1.x-SNAPSHOT (yes a literal x) and our CI system will replace the x-SNAPSHOT with a version number (using something similar to https://github.com/stephenc/git-timestamp-maven-plugin)... I do not expect this mechanism to be relevant to the bug, just noting it

Our downstream projects always depend on release versions of their upstream dependencies, thus quarkus-app will have something like:

<properties>
  <common-lib-version>1.435</common-lib-version>
</properties>
...
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.example.common-lib</groupId>
      <artifactId>common-lib-bom</artifactId>
      <version>${common-lib-version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
...
<profiles>
  <profile>
    <id>with-common-lib-snapshot</id>
    <properties>
      <common-lib-version>1.x-SNAPSHOT</common-lib-version>
    </properties>
  </profile>
</profiles>

If you open the project in your IDE you can enable or disable the with-common-lib-snapshot profile and get the classpaths merged or leave them separate depending on whether you are working on something that spans the two repositories or not.

The bug is that when quarkus-app has a dependency on a specific version of common-lib, say 1.435 and there is an unexpected local aggreagtor pom.xml in the parent directory of quarkus-app then both the 1.435 and the 1.x-SNAPSHOT versions of common-lib dependencies end up on the classpath and if any of those have beans.xml files you will end up with duplicate beans, but only when running mvn clean package quarkus:dev in the quarkus-app project

The duplicate beans disappear if you do any of the following:

• Activate the with-common-lib-snapshot profile, e.g. mvn clean package quarkus:dev -P+with-common-lib-snapshot
• Change the non-profile version of the property to 1.x-SNAPSHOT
• Set the property from the command line, e.g. mvn clean package quarkus:dev -Dcommon-lib-version=1.x-SNAPSHOT
• Edit the local aggregator to remove the <module>common-lib</module>
• Introduce a layer of separation between the local aggregator and the app, e.g. mkdir sep && mv quarkus-app sep && sed -i -e 's:module>quarkus-app:module>sep/quarkus-app:' pom.xml
• Run with the sibling helper functionality disabled, e.g. mvn clean package quarkus:dev -DnoDeps

NOTE: RE: "unexpected local aggregator". The quarkus-app pom.xml does not have a <parent> tag. It is a standalone pom.xml, so there is no requirement to walk up the <relativePath>../pom.xml</relativePath> default value that would apply if <parent> had been specified... also the local aggregator would not match the default value empty <groupId/><artifactId/> from the non-present <parent>.

Expected behavior

Sibling modules in the reactor should only be injected if the dependency version is the same as the version in the sibling module.

Actual behavior

Sibling modules in the reactor are always injected even when the version does not match. Additionally, this was only discovered because the part that removes the .jar from the sibling appears to actually be paying attention to the version and is thus noticing that they are not equivalent duplicates and thus we get two versions on the classpath.

To Reproduce
Steps to reproduce the behavior:

1. See bug description.

Configuration

# Add your application.properties here, if applicable.

Screenshots
(If applicable, add screenshots to help explain your problem.)

Environment (please complete the following information):

• Output of uname -a or ver:
• Output of java -version: 8 and 11
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.4.2
• Build tool (ie. output of mvnw --version or gradlew --version): Maven 3.6.3

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

https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/strange.20duplicate.20beans.20with.20.60quarkus.3Adev.60

[stephenc]

This is even more "fun" if the local aggregator doesn't have a <module>quarkus-app</module> then the common-lib two versions are still discovered... which indicates that the discovery of local code is even more zealous and finds a local reactor that doesn't even pull in the project that quarkus:dev is running