We need to exclude some of our dependencies because these dependencies must be provided by the customer due to license restrictions but the maven plugin is ignoring <scope>provided</scope> and also ignores <optional>true</optional>...
Comment From: wilkinsona
This is intentional but I don't think the documentation is clear, or if it is, I've failed to find the relevant section. The inclusion of provided dependencies is mentioned in the documentation on how to exclude dependencies. Optional dependencies aren't mentioned as far as I can see.
The exclusion approach is what you should use at the moment. #16563 and #22030 are tracking some improvements to it.
I'm wondering if we should rethink the approach to optional dependencies. Maven's documentation says the following:
Why use optional dependencies?
Optional dependencies save space and memory. They prevent problematic jars that violate a license agreement or cause classpath issues from being bundled into a WAR, EAR, fat jar, or the like.
Maven's own war plugin aligns with this general description and does not package optional dependencies, although some people would like it to do so.
Comment From: Captain-P-Goldfish
this extension would be great. It is a bit unlcear for other developers if they see that the dependencies must be explicitly excluded if they have already been set to optional=true.
Comment From: jeacott1
@wilkinsona the exclusion approach is completely impractical. it means keeping manual track of every unwanted provided dependency. For a project with hundreds of modules and hundreds more transitive dependencies which may be 'provided' its just folly. fwiw there are differences in provided vs optional, especially when it comes to how ide integration handles them so suggesting that we switch one for the other isnt always possible either. imo this should be a build time option with the default being to keep the default maven behaviour.
Comment From: wilkinsona
@jeacott1 I'm not sure what point you are trying to make. As the title of this issue describes, we already intend to make the packaging of optional dependencies a configurable option that is off by default. With #13289, we'll probably end up with a similar option for provided dependencies as well.
Comment From: jeacott1
@wilkinsona I'm trying to make the point that it should not relate to optional - but to 'provided' scopes too. thanks for the heads up re #13289 atm I am trying to convert a legacy project to an older spring boot (as a first step), and am staring at at least 50 imported swc files (flash intermediate compiled libraries), various jars, and a few zip files none of which should be in my lib folder but all of them are. dependencies are spread across hundreds of maven modules. trying to figure out how to deal with these now.
Comment From: victorherraiz-santander
Could you please consider provide a configuration switch for spring boot 2.x and default for 3.x.
Another use case, I use optional/excluded dependencies to slightly modify the behaviour in local and ci (e.i. expanded) environments without any profile value (e.g. logging format)
Comment From: jeacott1
for my case, and for anyone else looking for a sledgehammer solution, here's what I'm doing to 'fix' my issue. This is for a legacy project, I haven't yet identified all the jars, but just ripping out the swc and zip files here has reduced my boot executable jar by over 100MB. drop this in after the spring-boot-maven-plugin
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>truezip-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>remove-a-file</id>
<goals>
<goal>remove</goal>
</goals>
<phase>package</phase>
<configuration>
<fileset>
<!-- note how the archive is treated as a normal file directory -->
<directory>${project.build.directory}/${project.build.finalName}.${project.packaging}</directory>
<includes>
<include>BOOT-INF/lib/*.swc</include>
<include>BOOT-INF/lib/framework-4.1.0.16076-configs.zip</include>
</includes>
</fileset>
</configuration>
</execution>
</executions>
</plugin>