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

**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.
2. 
3. 

**Configuration**
```properties
# 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


Changed files:
devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java

diff --git a/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java b/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java
index f69f4bda765..37222164dc8 100644
--- a/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java
+++ b/devtools/maven/src/main/java/io/quarkus/maven/DevMojo.java
@@ -925,6 +925,11 @@ private List<LocalProject> filterExtensionDependencies(LocalProject localProject
             if (project == null) {
                 continue;
             }
+            if (!project.getVersion().equals(a.getVersion())) {
+                getLog().warn(depKey + " is excluded from live coding since the application depends on version "
+                        + a.getVersion() + " while the version present in the workspace is " + project.getVersion());
+                continue;
+            }
             if (project.getClassesDir() != null &&
             //if this project also contains Quarkus extensions we do no want to include these in the discovery
             //a bit of an edge case, but if you try and include a sample project with your extension you will