Improve repackage exclude to be able to specify a pattern

[snicoll]

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.

[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>

[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.

[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.

[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.

[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.