SpringBoot Improve repackage exclude to be able to specify a pattern

We've add a few reports around dependency exclusion for the repackage goal with Maven. The fact transitive artifacts are not filtered out is annoying and certain arrangements require a large number of artifacts to be defined.

While avoiding such practice in application's module should be preferred, it's not always possible. This issue is about reviewing our current support and investigating how we could improve the experience for this.

Comment From: JoshuaJeme

Can we provide a spi which allow the user to add custom filters?

org.springframework.boot.maven.FilterProvider for example, has a method like getFilters

public interface FilterProvider {
    List<ArtifactsFilter> getFilters();
}

User can provide a jar contain the Provider and config it through the dependency of maven plugin

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <version>2.2.0.M2</version>
  <dependencies>
    <dependency>
      <groupId>com.demo</groupId>
      <artifactId>filter-provider</artifactId>
      <version>0.0.1</version>
    </dependency>
  </dependencies>
</plugin>

Comment From: snicoll

Thanks for the suggestion. That was one of the option when we brainstormed but we'd like to keep it as a fallback. The user still has to exclude transitive dependencies with more configuration and code to write. We'd like to research if we can't make exclude do that automatically instead.

Comment From: JoshuaJeme

Thanks for the suggestion. That was one of the option when we brainstormed but we'd like to keep it as a fallback. The user still has to exclude transitive dependencies with more configuration and code to write. We'd like to research if we can't make exclude do that automatically instead.

THX for the reply, I'm curious about what are the rest options, can you give more detail?

Another option I had thought is compound GAV pattern, like groupId:artifactId:version:scope, each part can use * as wildcard match (like https://maven.apache.org/docs/3.2.1/release-notes.html).

It's more flexable but still can't satisfy all the scenes, so I think the fallback solution is needed, which give the user a chance to add custom logic, it does has more configuration and code but better than no way.

Comment From: snicoll

Yeah the wildcard thing was also discussed. What we'd like to research is a way to make exclude work the same way as the Maven model does. That way, you'd define the top-level artifact(s) you need to exclude and their transitive dependencies would be excluded as well. That should provide enough flexibility for everyone.

Comment From: kakawait

That way, you'd define the top-level artifact(s) you need to exclude and their transitive dependencies would be excluded as well

Could be strange behavior to excludes every transitive dependencies when using <excludes><exclude>...</exclude></excludes> pattern because (if I'm not wrong) when using it inside <dependency></dependency> it does not exclude transitive.

I like both @JoshuaJeme proposal IHMO. And since I truly think it's an advance / poweruser usage I don't see any problem to only expose SPI version.

Comment From: qzmer1104

It's 2024 now. Not solved yet?

Comment From: philwebb

@qzmer1104 The issue is still open and is something we'd like to fix when we can find the time.

Comment From: JoshuaJeme

@qzmer1104 The issue is still open and is something we'd like to fix when we can find the time.

It has been many years, can we consider the Maven ArtifactsFilter SPI solution? Done is better then perfect. I'm very happy to contribute if I can.