你好！这个问题其实是Maven依赖解析机制下的典型场景，你的思路方向完全是对的，咱们来把这件事捋清楚：

首先得明白为什么会出现这个情况：Maven在处理依赖时，核心是读取对应构件的pom.xml元数据，哪怕你指定了带jar-with-dependencies classifier的Jar包，它还是会默认去解析Project A的pom里声明的所有传递依赖——因为pom才是Maven识别依赖关系的依据，带classifier的Jar只是额外生成的构件而已。

你想到的通过<exclusions>排除所有传递依赖的方法，不仅是可行的，也是官方认可的常规解决方案。具体来说就是使用通配符*来匹配所有groupId和artifactId，一次性把Project A的所有传递依赖都排除掉：

<dependency>
    <groupId>mygroup</groupId>
    <artifactId>myartifact</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <classifier>jar-with-dependencies</classifier>
    <exclusions>
        <exclusion>
            <groupId>*</groupId>
            <artifactId>*</artifactId>
        </exclusion>
    </exclusions>
</dependency>

这样配置后，Maven就只会下载你需要的那个包含所有依赖的Jar包，不会再去拉取Project A pom里声明的那些传递依赖，完美解决构建速度慢的问题。

当然，还有一种进阶思路：如果你有权限修改Project A的构建配置，可以在生成jar-with-dependencies的同时，生成一个不包含传递依赖的精简pom文件。比如用maven-shade-plugin替代maven-assembly-plugin，它支持配置生成一个"shaded"版本的pom，自动移除原有的依赖声明。不过这种方式需要改动Project A的构建流程，如果你只是想快速解决Project B的问题，直接用排除法显然更高效、更省心。

总结一下：你想到的通配符排除方法就是最直接、最官方的解决方案之一，完全可以放心使用。

备注：内容来源于stack exchange，提问作者Baradè