see gh-12794.

Comment From: snicoll

@vision-ken we'd like to understand why you need this feature. Can you please provide more details?

Comment From: vision-ken

@snicoll Since Spring Boot provide -Dloader.path feature, I'd like to place dependencies outside of a Spring Boot "fat JAR" with maven-dependency-plugin and spring-boot-maven-plugin plugins.

Now I have a spring cloud project which has many of own business maven modules, these modules need to package into "fat JAR", because they change often. If spring-boot-maven-plugin dosn't provide includeGroupIds feature, I have to do like this:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>3.1.0</version>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/dependency</outputDirectory>
                            <excludeTransitive>false</excludeTransitive>
                            <stripVersion>false</stripVersion>
                            <includeScope>runtime</includeScope>
                            <excludeGroupIds>
                                io.prong,
                                io.prong.boot,
                                io.prong.cloud
                            </excludeGroupIds>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <layout>ZIP</layout>
                    <includes>
                        <include>
                            <groupId>io.prong</groupId>
                            <artifactId>aaaa</artifactId>
                        </include>
                        <include>
                            <groupId>io.prong</groupId>
                            <artifactId>bbbb</artifactId>
                        </include>
                        ...
                        <include>
                            <groupId>io.prong.boot</groupId>
                            <artifactId>cccc</artifactId>
                        </include>
                        <include>
                            <groupId>io.prong.boot</groupId>
                            <artifactId>dddd</artifactId>
                        </include>
                        ...
                        <include>
                            <groupId>io.prong.cloud</groupId>
                            <artifactId>eeee</artifactId>
                        </include>
                        <include>
                            <groupId>io.prong.cloud</groupId>
                            <artifactId>ffff</artifactId>
                        </include>
                        ...
                    </includes>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

Every time the artifactIds under groupIds io.prong、io.prong.boot、io.prong.cloud change，I have to change pom already.

So, if spring-boot-maven-plugin provide includeGroupIds, things become simple:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>3.1.0</version>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/dependency</outputDirectory>
                            <excludeTransitive>false</excludeTransitive>
                            <stripVersion>false</stripVersion>
                            <includeScope>runtime</includeScope>
                            <excludeGroupIds>
                                io.prong,
                                io.prong.boot,
                                io.prong.cloud
                            </excludeGroupIds>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>${spring.boot.version}</version>
                <configuration>
                    <layout>ZIP</layout>
                    <includeGroupIds>
                        io.prong,
                        io.prong.boot,
                        io.prong.cloud
                    </includeGroupIds>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

I don't need to change the pom any more, because groupIds are stable.

Comment From: nosan

@snicoll done :)

Comment From: snicoll

I've polished the PR and it's ready to go but I am not sure we should merge it. The purpose of exclude is to be able to remove things that should not be part of the app (while being present in the pom). An important part of this is that it also applies to the classpath we use to run the app.

So, say you have org.acme:lib in your pom and flagging it as provided is useless as we take those anyway. That feature allows you to remove it from the fat jar and If you run the app with the plugin (mvn spring-boot:run) this jar will not be on the classpath as well. This is an interesting pairing feature IMO.

Now, if we introduce this parameter things go sideways. It is a corner case to create a fat jar that can't run on its own (it needs an extra lib directory with stuff that are shared or some loader config). If we merge this, then users won't be able to use mvn spring-boot:run with such configuration. IMO that's a blocker.

Comment From: snicoll

@nosan thanks a lot for the PR but we've decided not to add that feature for the reasons exposed above.

@vision-ken if you want to repackage your jar in such a way that it can't run without additional libs, please have a look to custom layout.

Comment From: nosan

@snicoll it's ok, you know much better should it be merged or not, if you feel that feature will bring some sideways, it's much better not to add it at all IMO.

Comment From: Seriels

Excuse me, how to solve the above problem

Comment From: wangliang181230

I've polished the PR and it's ready to go but I am not sure we should merge it. The purpose of exclude is to be able to remove things that should not be part of the app (while being present in the pom). An important part of this is that it also applies to the classpath we use to run the app.

So, say you have org.acme:lib in your pom and flagging it as provided is useless as we take those anyway. That feature allows you to remove it from the fat jar and If you run the app with the plugin (mvn spring-boot:run) this jar will not be on the classpath as well. This is an interesting pairing feature IMO.

Now, if we introduce this parameter things go sideways. It is a corner case to create a fat jar that can't run on its own (it needs an extra lib directory with stuff that are shared or some loader config). If we merge this, then users won't be able to use mvn spring-boot:run with such configuration. IMO that's a blocker.

@snicoll @nosan

I don't think mvn spring boot:run should be considered when adding support for includeGroupIds, because includes is the same. Since includes is supported, includeGroupIds should also be supported. Not all developers will execute mvn spring boot:run.

Comment From: iamnewsea

插件应该提供最大的灵活性。不限制使用方式， includeGroupIds 明显比 includes 更实用。

Comment From: wangliang181230

插件应该提供最大的灵活性。不限制使用方式， includeGroupIds 明显比 includes 更实用。

@iamnewsea 我临时开发了一个插件 icu.easyj.maven.plugins:easyj-maven-plugin:1.0.9，用于支持 includeGroupIds，欢迎使用。 原理是反向的利用 spring-boot 插件的 excludeGroupIds 属性，达到 includeGroupIds 的效果。

<build>    
    <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <version>${spring-boot.version}</version>
    </plugin>
    <plugin>
        <groupId>icu.easyj.maven.plugins</groupId>
        <artifactId>easyj-maven-plugin</artifactId>
        <version>1.0.9</version>
        <executions>
            <execution>
                <id>spring-boot-extend</id>
                <phase>prepare-package</phase>
                <goals>
                    <goal>spring-boot-extend</goal>
                </goals>
                <configuration>
                    <includeGroupIds>groupA, groupB, groupC</includeGroupIds>
                </configuration>
            </execution>
        </executions>
    </plugin>
</build>

Comment From: iamnewsea

@wangliang181230 牛逼！