Update maven plugin to support smart exclusions #649
Comments
|
See #413 (comment) for some background of why we currently bundle |
|
I'm targeting this to 1.1 and I'm tempted to change the behavior at that point to exclude provided dependencies by default. The lombok example in #674 is the most compelling case that I've seen so far. |
|
Quick summary of our brainstorming goes towards changing the behaviour and exclude In an ideal situation, the plugin should be updated to support an implicit list of "container dependencies" so instead of relying on I need to investigate that a bit further to see if that's doable (i.e. via ProjectDependenciesResolver) |
|
okay so back on this issue. The container should be on the classpath as the story is to start the app from the IDE by invoking a simple main method and no further tuning of the classpath is foreseen. The original issue remains though (the container itself is specified through that means) and both the As our intend is to define the container through the |
Previous to this commit, any groupId starting with one of the configured exclude would be excluded as well. This potentially leads to unintentional dependency filtering: for example the GroupIdFilter with an exclusion of "org.springframework" also removes "org.springframework.boot" dependencies. Add MatchingGroupIdFilter that uses an exact match instead. See #649
This commit provides several options to exclude one or more dependencies: * excludes allows to specify an arbitrary number of exclude sub element defining the groupId and artifactId of the dependency to exclude * excludedGroupIds defines the comma separated list of groupIds to exclude * excludeArtifactIds defines the comma separated list of artifactIds to exclude While any artifact can be excluded, this is designed to exclude provided-scoped dependencies that should not be bundled in the executable jar/war. The outcome of java -jar myapp.jar should be consistent with the run goal: these exclusions are therefore applied to the classpath that the run goal computes to launch the application. This commit also adds some integration tests and updates the plugin's documentation Fixes spring-projectsgh-649, spring-projectsgh-650 and spring-projectsgh-674
Previous to this commit, any groupId starting with one of the configured exclude would be excluded as well. This potentially leads to unintentional dependency filtering: for example the GroupIdFilter with an exclusion of "org.springframework" also removes "org.springframework.boot" dependencies. Add MatchingGroupIdFilter that uses an exact match instead. See spring-projects#649
Boot's maven plugin creates executable jar/war with a somewhat specific semantic behind Maven's
providedscope that would need smart exclusions options for advanced use casesA lot of projects out there are relying on the
providedMaven scope: plugins dependency, annotation processor, etc. In the end, this jar file should not be placed at all in the executable. There are other (nasty?) use cases that requires some advanced options of, for instance, thewar-plugin:packaging-excludesis the most obvious (see some doc).Boot brings a new use case: executable jars. Previously, Maven users were relying on features of either the Maven lifecycle (running custom code before the archive is packaged) or the war plugin. With executable jars, those features are gone.
A first attempt to solve this issue would be to introduce some smart exclusions, similar to the
copy-dependenciesgoal of themaven-dependency-plugin, that is:One would expect that the transitive dependencies of excluded dependencies are also excluded. This can tricky to achieve but the
maven-dependency-treeshared component can help.The text was updated successfully, but these errors were encountered: