Allow exclusions in Maven plugin to take wild cards

[odrotbohm]

The Spring Boot Maven plugin allows defining exclusions that will not make it into the final JAR. If quite a few similarly named artifacts are to be listed, that list gets rather long. It would be cool if wildcards were allowed in group and artifact ids. E.g. all Spring Boot starter JAR (that do not contribute code or resource to the runtime behaviour) could be excluded by:

<exclusions>
  <exclusion>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-*</artifactId>
  </exclusion>
</exclusions>

[pgerhard]

Since I am currently also fighting with the issue of having provided dependencies packaged into my final JAR when using the spring-boot-maven-plugin, I came across this ticket and #16563. They appear to be discussing a similar issue so its unclear where I should provide my input, maybe a consolidation would be helpful to focus the discussion.

But to the topic at hand. The issues that have requested a change like this usually stem from people using scope provided or optional=true and then being surprised that spring-boot-maven-plugin ignores this. While I understand the underlying reason, as was provided by @philwebb in this comment, and have found the behaviour helpful in the past, I also feel that requests to allow for the enabling of the default behaviour are legitimate. In my opinion adding wildcards or patterns (as is being suggested in #16563) is a clunky solution to the problem. It introduces various downsides

• More parts of the POM must potentially be updated during maintenance
• Reasoning about which dependencies will be included and which will be ignored becomes harder (especially if regex patterns will be allowed)
• Can break easily when dependencies change their artifact or group ids and someone forgets to update the exclusion
• Handling of wildcards and patterns inside spring-boot-maven-plugin is an additional source of bugs, which can result in hard to debug behaviour or in the unintended releasing of private jars (e.g. proprietary annotation processors)
• Since exclusions do not affect transitive dependencies, if the excluded artifact adds a new dependency this will suddenly be packaged, even if it is not required since the dependency declaring it is being excluded

What are upsides of this approach when compared to allowing the enabling of Mavens default mechanisms for solving the same problem, as was requested here #13289? I completely agree that this should not be the default behaviour (as is being suggested in #25403), see comment linked above, but I feel that using wildcards or patterns is a work-a-round for a problem that already has a solution built into Maven.

[philwebb]

We discussed this again on our call and we're going to re-open #13289.

[philwebb]

I'm going to close this one since #22036 deals with the starters (which I think originally drove the issue) and I'd like to see how #13289 plays out before we add more options.