Bug using a maven classifier in dev mode

[rmanibus]

Describe the bug
I use a maven classifier to produce a shared jar between multiple microservices.
It seems that when runing mvn quarkus:dev, the qualifier is ignored and the full jar is used (beans outside the shared package are instantiated)

Expected behavior
Only the classes in the shared Jar are indexed when running mvn quarkus:dev.

Actual behavior
All the beans are present in the microservices (even those outside the shared package)

To Reproduce
Reproduced here:
https://github.com/rmanibus/Quarkus-Test
in the module2, when running mvn quarkus:dev all beans from module1 are instantiated (AppleResource in module1.app, which is not included in the shared jar).

Additional context

This only happen with the dev mode, it's working with the runner.

Also Adding

quarkus.index-dependency.module1.group-id=org.acme
quarkus.index-dependency.module1.artifact-id=module1
quarkus.index-dependency.module1.classifier=shared

throw the following error:

[error]: Build step io.quarkus.deployment.index.ApplicationArchiveBuildStep#build threw an exception: java.lang.RuntimeException: java.lang.RuntimeException: Could not resolve artifact org.acme:module1:shared. Please make sure it is present and contains a META-INF/MANIFEST.MF file. Note that artifacts that are part of the same project may not always be resolvable, in this case you should generate a META-INF/jandex.idx file instead using the Jandex Maven plugin.

[quarkusbot]

/cc @quarkusio/devtools

[rmanibus]

cc @aloubyansky

[rmanibus]

will do some test here #9337
Edit: more complicated than I initially thought

[aloubyansky]

This issue is about applying filtering to the classes dir. I.e. picking up a subset of all the classes in the target/classes instead of all of them.
In this specific case, this is expressed in the maven-jar-plugin configuration.
During the tests we don't see the dependency project being packaged with a classifier, so we cannot match the dependency artifact to the locally discovered project, our workspace resolver will return null for it. So this artifact dependency will be resolved by Maven from the local repo. And if it does not exist, it'll fail, of course.

[aloubyansky]

I'm not starting to work on this right now, so I unassigned myself.

[rmanibus]

As a workaround runing mvn quarkus:dev -DnoDeps is working, but dependencies must be installed in the local repo before.

[geoand]

Is this still an issue?

[rmanibus]

I just refreshed the demonstrator, it was done with quarkus 1.
I managed to make it work, but it is somewhat cumbersome.

I had to add the jandex plugin in the first module, that contain the shared classifier jar (was this not a thing in quarkus 1 ?).

Now by default the jandex index contains every class from the module, so if it is included like this in the shared jar, the receiving application will fail because the jandex contains class that are not in that jar.

But it is possible to filter the content of the jandex:

                      <configuration>
                            <fileSets>
                                <fileSet>
                                    <includes>
                                        <include>**/shared/*.class</include>
                                    </includes>
                                    <directory>${project.build.directory}/classes</directory>
                                </fileSet>
                            </fileSets>
                        </configuration>

With this config, it works as expected.
Not sure if we could do anything to simplify the creation of shared artifact (somehow synchronize what is in the classified jar and what is in the jandex)

[geoand]

Thanks for the update!

[aloubyansky]

@rmanibus if you add the maven-jar-plugin config to the module1 it should work. Otherwise, running with -Dquarkus.bootstrap.effective-model-builder should help in this case.

[aloubyansky]

I opened #44487 that fixes a few issues and will make it easier to support this kind of use-case.
With that change you can set quarkus.bootstrap.effective-model-builder as a POM property. This is necessary if you define shared JAR config in the parent POM and if you want to launch dev mode w/o installing the project artifacts in the local repository.

But the Jandex plugin config will either have to be adjusted with the filtering (as you found out) or simply removed.