Java 在Maven shaded jar中包含第三方jar，而不将其添加到本地存储库

我已经在Stack Overflow上找到了一个答案，即如何在项目中包含第三方JAR而不将其安装到“本地存储库”：

但是，当我使用Maven Shade插件创建一个包含项目所有依赖项的JAR时，第三方JAR并不是自动包含的

如何让Maven Shade插件将这样的第三方JAR添加到着色JAR中

---

根据得到的答案，我成功了。我所做的是，在pom.xml的开头添加了以下代码片段：

<repositories>
  <repository>
    <id>repo</id>
    <url>file://${basedir}/repo</url>
  </repository>
</repositories>

现在我可以将其签入到版本控制中，并且没有本地或远程依赖项

但是，当我使用Maven Shade插件创建一个包含项目所有依赖项的JAR时，第三方JAR并不是自动包含的

是的，因为假定

系统

作用域的依赖项总是存在的（这正是

系统

作用域的内容），所以不包括它们。人们实际上不理解什么是

系统

范围依赖，他们只是不断滥用它们（是的，这就是滥用），然后产生副作用并想知道为什么（正如Brian在他的文章中指出的）

我已经写过，关于这一点，在99%的情况下，

系统

范围依赖应该避免。我再重复一遍迷你指南上说的话：

• 系统

  ：此依赖关系在项目生命周期的某些阶段是必需的，但是特定于系统的不鼓励使用此范围：这被认为是一种“高级”功能，只有在您真正了解其使用的所有后果时才应使用，如果不是实际上不可能量化的话，这可能是非常困难的。根据定义，此范围使您的构建不可移植。在某些边缘情况下，这可能是必要的。系统范围包括
  元素，该元素指向本地计算机上此依赖项的物理位置。因此，它被用来指出现在给定本地机器上而不是存储库中的某些工件；其路径可能因机器而异。systemPath元素可以引用其路径中的环境变量：

  ${JAVA_HOME}

因此，与其使用

系统

范围，不如：

• 通过

  install:install file

  将库添加到本地存储库。这是一种快速而肮脏的工作方式，如果你独自一人，这可能是一种选择，但它会使你的构建变得不可移植
• 安装并运行“企业存储库”，如Nexus、Archiva或Artifactory，并通过

  deploy:deploy file

  添加库。这是理想的情况
• 按照中所述设置基于文件的存储库，并将库放在其中。如果您没有公司存储库，但需要团队合作，并且不想牺牲可移植性，那么这是最好的折衷办法

---

请停止使用

系统

作用域。

Maven addjars插件解决了此问题-请参阅

用于将我的库包含在所有jar中。i、 e:

<build>
    <resources>
        <resource>
            <directory>${project.basedir}</directory>
            <includes>
                <include>lib/*.jar</include>
            </includes>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <createDependencyReducedPom>false</createDependencyReducedPom>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

${project.basedir}
lib/*.jar
org.apache.maven.plugins
maven阴影插件
2.3
假的
包裹
阴凉处

如果您只需要一个快速而肮脏的解决方案，您可以将提取的jar文件的内容添加到您的src/main/resource目录。

问题不在于人们喜欢使用错误的方法，或者，这样做是为了激怒人们——问题是这些东西都没有明确的记录，也没有在互联网上给出实现这些东西的方法。不可能让人们对创建“企业存储库”或使用maven感到粗糙，因为这意味着没有针对人们遇到的常见情况的文档——他们总会找到一种方法。好吧，我想，关于实用解决方案的文档，您一定是对的。关于

系统

范围，也许Maven人员应该更清楚地表明，它不是向构建添加“随机”依赖项的解决方案。但是

系统

范围本身就是。另一个问题是，使用本地jar没有简单的方法：承认它，系统范围可能是错误的，让头脑清醒的人畏缩，但初学者需要让东西工作起来。我有一个明天10点到期的项目⁰⁰, 到时候需要一个有阴影的罐子。不得不建立回购协议让我的眼睛向后翻，我喜欢这个答案，但这并不能回答问题。教人们这是一种不好的做法是很好的，但在某些情况下确实需要这样做。经过13年的JDev实践，我终于来到了这一刻，我真的需要这个，读这个而不是真正的解决方案并不酷。如果您感兴趣，我刚刚发现了一个仅许可用于一个项目的库，因此这不会用于central repo甚至公司repo，我也不会告诉其他开发人员将此安装到其本地存储库作为构建项目的先决条件为什么安装到本地repo是不可移植的？我可能错了，但是如果您将安装文件绑定到

clean

阶段（如中所述），那么jar将被安装。这可能会导致哪些可移植性问题？Unformatelly需要Maven 3.0。3@Daniel你的意思是说你至少需要Maven 3.0.3，还是说它不支持新版本？Maven 3.0.3发布于2011-03-04，如果你不能运行，那么你有严重的问题！看看addjars，它自2012年以来就没有发布过

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
    -Dfile=<my-jar>.jar -DgroupId=dummy -DartifactId=dummy
    -Dversion=0.0.0 -Dpackaging=jar -DlocalRepositoryPath=`pwd`/repo/

repo/dummy/dummy/0.0.0/dummy-0.0.0.jar
repo/dummy/dummy/0.0.0/dummy-0.0.0.pom
repo/dummy/dummy/maven-metadata-local.xml

<build>
    <resources>
        <resource>
            <directory>${project.basedir}</directory>
            <includes>
                <include>lib/*.jar</include>
            </includes>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <createDependencyReducedPom>false</createDependencyReducedPom>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>