Bug Report - .jqassistant.yml of a maven module not applied

[bragern]

This ticket duplicates the first issue from jqassistant-archive/jqa-maven-plugin#83 which to me is not fixed. As I cannot reopen a ticket, I opted for creating a new one.

Bug Description

jqassistant.yml on a Maven child module is not actually applied if a build is started on the parent. The log suggests to load the configuration but actually it does not execute the analysis. If the build is started on the child module, everything works as intended.

Expected Behaviour

No matter if the build is started from parent or module, the configured group in '.jqassistant.yml' of the
module should be used for jQA analysis.

Your Environment

• JDK: jdk-17.0.2
• OS: Windows 11 Enterprise
• Maven: 3.8.6
• jQA: 2.3.0

How can we reproduce the bug?

• Download https://github.com/bragern/jqa-groups-test
• execute 'mvn clean install' on 'jqa-groups-test/jqa-groups-test-module/'
• execute 'mvn clean install' on 'jqa-groups-test/'
• compare build logs

Child module build

\jqa-groups-test\jqa-groups-test-module> mvn clean install
[...]
[INFO] --- jqassistant-maven-plugin:2.3.0:analyze (default-cli) @ jqa-groups-test-module ---
[INFO] Loading configuration from file '\jqa-groups-test\jqa-groups-test-module.jqassistant.yml'.
[INFO] Rules directory '\jqa-groups-test\jqa-groups-test-module\jqassistant' does not exist, skipping.
[INFO] Executing analysis for 'jqa-groups-test-module'.
[...]

=> Configuration is loaded, analysis is started - all good ✅.

Parent build

\jqa-groups-test> mvn clean install
[...]
[INFO] --- jqassistant-maven-plugin:2.3.0:analyze (default-cli) @ jqa-groups-test-module ---
[INFO] Loading configuration from file '\jqa-groups-test\jqa-groups-test-module.jqassistant.yml'.
[INFO] Loading configuration from file '\jqa-groups-test\jqa-groups-test-module.jqassistant.yml'.
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ jqa-groups-test-module ---
[...]

=> Configuration is loaded twice (sketchy already), analysis is not started, next build step is commenced - not good ❌

Definition of Done for the Implementers

Remove this hint: these checkboxes can be checked like this: [x]

• We got a final feedback from the reporting user (if applicable)
• Unittests have been written (if applicable)
• Integration tests have been written (if applicable)
• Test coverage is the same or even better then before (if applicable)
• Documentation has been written (if applicable)
• Added a note on the new feature to the release notes (if applicable)

[DirkMahler]

I had a look at the provided example, the situation is a bit more complex than loading configuration file(s).

The current setup implies that both (the parent and the module) are treated as one project with one database covering both (this is given by the Maven plugin declaration in the parent). For that reason analyze is skipped in the module, but there's no group config for the parent, leading to no analyze at all.

The main question is: What do you want to achieve? Is it correct to assume that you want an aggregator project that builds several modules at once where each of the modules is treated as a separate project in the sense of scanning and analysis (each using its own database instance)?

[bragern]

So I should be able to fix it with a group config or by removing the plugin from the parent?

What I want to achieve is pretty much what you described: I have a parent with several child modules that I want to scan separately and store the results in a separate database per child module.

[DirkMahler]

This setup is already supported and should work:

• The plugin declaration must either be removed from the parent pom.xml or moved to a pluginManagement section if certain settings shall be standardized for the modules. It then makes sense to have the execution already defined here (it's currently in the module).
• The configurationLocation parameter must be removed from the module.

Please give it a try and provide feedback if it works as expected. Nevertheless we will check if we can remove the duplicated reading of the config file (which is caused by specifying the configurationLocation parameter).

[bragern]

Thanks for clarification. Following your hints, I got it to work as expected.