quarkusio / quarkus-platform-bom-generator

Quarkus platform BOM generating tools
Apache License 2.0
9 stars 18 forks source link

Fix inclusion/exclusion inconsistency #342

Open robobario opened 1 month ago

robobario commented 1 month ago

Closes #320

If we decide a root artefact is allowed by the include/exclude list we use the same logic to decide if we should process it as a node.

Note this changes the behaviour, an inclusion rule will beat an exclusion rule.

Context

We are using ProjectDependencyResolver to discover project dependencies and want to be able to configure it like:

excludePattern: "org.group:*:*"
includePattern: "org.group:specific:*"

However in this configuration org.group:specific:* is not resolved as the exclusion takes precedence. Then looking into the code we see some usages where inclusion beats exclusion and wonder what the intent of the inclusion/exclusion lists are.

This is more the start of a conversation as there are numerous places where the include/exclude list are consulted. For example when collecting projectBomConstraints it has different logic again:

if (includeSet.isEmpty()) {
                    collect = d.getGroupId().startsWith(config.getProjectBom().getGroupId()) && !isExclude(d);
                } else {
                    collect = !isExcluded(d) && isIncluded(d);
                }

where it applies this groupId restriction if there are no explicit inclusions else it requires it to be explicitly included.

There are other places in the resolver where we only check the exclusion list or inclusion list.

The javadoc on ProjectDependencyConfig is ambiguous around how getIncludePatterns and getExcludePatterns interact and how they relate to getIncludeArtifacts.

It feels like there should be some consistent way that the inclusion/exclusion rules are applied to dependencies.

robobario commented 1 month ago

Alternatively if exclusion should beat inclusion (hard to make everyone happy :grin:), we should add that to the javadoc and put tests on it.