[MSHADE-573] Fix missing exclusions - direct and transitive

[marwin1991]

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes. =[MSHADE-202] When promoteTransitiveDependencies=true, some <exclusions> are stripped from the dependency-reduced-pom #573
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MSHADE-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MSHADE-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the
  commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

Pull Request Description

Preserve original and transitive exclusions in dependency-reduced-pom to improve POM correctness

Summary

This PR fixes a long-standing issue where exclusions declared in the original pom.xml — including wildcard and transitive exclusions — were not propagated to the generated dependency-reduced-pom.xml. As a result, the reduced POM could reintroduce dependencies that the user had explicitly excluded.

The change introduces a dedicated exclusion resolution step and updates the reduced-POM generation so that:

• Direct exclusions defined on dependencies in the original POM are preserved.
• Transitive exclusions (required to keep the effective dependency graph consistent) are carried over.

Motivation and context

Example of the incorrect behavior (existing upstream case):

• Source POM defines a wildcard exclusion on a dependency:

  <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>itextpdf</artifactId>
      <version>5.5.13.3</version>
      <exclusions>
          <exclusion>
              <groupId>*</groupId>
              <artifactId>*</artifactId>
          </exclusion>
      </exclusions>
  </dependency>

• But the resulting dependency-reduced-pom.xml previously dropped the exclusions entirely:

  <dependency>
      <groupId>com.itextpdf</groupId>
      <artifactId>itextpdf</artifactId>
      <version>5.5.13.3</version>
  </dependency>

Reference:

maven-shade-plugin/src/it/projects/MSHADE-467_parallel-dependency-reduced-pom/pom.xml

Line 64 in 073e7ca

<groupId>com.itextpdf</groupId>

With this PR, exclusions like the above (including */*) are preserved in the reduced POM.

What changed

• Core logic
  • Added DependenciesExclusionResolver to compute effective exclusions for both direct and transitive dependencies.
  • Introduced DependencyList utility to help build the reduced POM dependency set with proper scopes and exclusions.
  • Refactored ShadeMojo to apply resolved exclusions during reduced POM generation and to streamline transitive dependency handling.
• Tests
  • Added a new IT project: dep-reduced-pom-with-transitive-dependencies-with-exclusions (verifies propagation of direct and transitive exclusions).
  • Updated/added expected reduced POMs for MSHADE-467 parallel builds (shadeMT1..shadeMT4/expected-dependency-reduced-pom.xml).
  • Kept changes minimal for now to validate the approach first.

Behavior before vs after

• Before: dependency-reduced-pom.xml could omit user-declared exclusions and omit required transitive exclusions, causing unexpected dependencies to appear for consumers.
• After: The reduced POM preserves original exclusions and includes necessary transitive exclusions, ensuring the effective dependency graph remains consistent.

Why this matters

• Ensures consumers of the shaded artifact do not unintentionally pull dependencies that were explicitly excluded.
• Aligns the reduced POM with what users expect from the original POM’s dependency declarations.
• Improves reproducibility and clarity of dependency management for downstream builds.

Testing

• Added basic integration tests to demonstrate the corrected behavior:
  • src/it/projects/dep-reduced-pom-with-transitive-dependencies-with-exclusions/*
  • Updated MSHADE-467 parallel ITs with expected-dependency-reduced-pom.xml snapshots for visibility into changes, for example:
    • src/it/projects/MSHADE-467_parallel-dependency-reduced-pom/shadeMT1/expected-dependency-reduced-pom.xml

Note: At this stage only the foundational tests are included. If the overall approach is accepted, I will add more test coverage, including corner cases (wildcards, multiple excludes, ordering, and mixed scopes).

Open question: how strict should IT verification be?

Currently, to make differences obvious, I added snapshot files like:

• src/it/projects/MSHADE-467_parallel-dependency-reduced-pom/shadeMT1/expected-dependency-reduced-pom.xml

Is a strict one-to-one comparison (expected vs. generated reduced POM) desirable for ITs? My recommendation:

• Prefer structure-aware assertions over literal byte-for-byte equality to avoid false negatives due to formatting, ordering, or benign metadata changes. Options:
  • Normalize and compare: strip whitespace, sort dependency and exclusion lists where ordering is non-semantic, and compare normalized XML.
  • XPath-based checks: assert presence of specific dependencies and their exclusion blocks, and absence of those that should remain excluded.
• We can keep a small number of full-file snapshots for human readability, but rely on normalized or XPath checks for robustness.

I’m happy to implement whichever verification approach the project prefers.

[marwin1991]

Preserve only for testing.

I’m wondering if I should add a 1:1 comparison between the generated reduced-pom.xml and the expected one (the expected file was generated in the main branch).

Then, in a pull request, maintainers could see the diff in the expected reduced-pom.xml, which would make it clearer how the pull request affects the plugin.

I’m a maintainer of a changelog plugin, and in that project I verify one-to-one changes for every integration test. This way, after community contributions, I can clearly see how they influence the final artifact—instead of just guessing what changed.

[marwin1991]

FYI @slachiewicz @Bukama @slawekjaranowski @olamy