当前位置：文江博客话题详情

如何在不使用本地安装的工件的情况下进行构建

发布于 2024-07-28 08:17:58 字数 153 浏览 10 评论 0原文

有没有办法强制 Maven 使用远程工件而不是安装在您的计算机上的工件？因为我担心运行时错误而不是编译错误，构建服务器不是有效的选项。

PS 我知道我可以删除或重命名 .m2 文件夹，但我敢打赌有一些更聪明的方法可以做到这一点。也许是一些插件或特殊的命令参数？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

傲娇萝莉攻 2024-08-04 08:18:10

我认为没有真正的方法可以满足您的要求。您可以根据 SNAPSHOT 版本进行研究（但这意味着将上游项目的版本字符串更改为 SNAPSHOT 版本）。

顺便说一句，最近的 Java Posse 剧集 (#268)。我认为他们最终没有找到解决方案，但你可能会得到一些好主意。

我也喜欢一些Rich Seller 的想法，我会亲自研究一下。

回复收藏 0 原文

无远思近则忧 2024-08-04 08:18:08

没有本地存储库意味着您的类路径几乎完全由远程服务器上的 URL 组成。我不明白为什么会支持这个，因为执行会很糟糕，并且任何断开的连接都会导致类加载器问题。拥有本地存储库可确保 jar 在编译/执行开始之前可用。

还要考虑 WAR 和 EAR 项目（以及许多使用依赖插件的项目）依赖于下载 jar 来完成其打包。如果每次构建时都必须从远程存储库检索这些内容，则会产生巨大的开销。我很确定中央的管理者不会热衷于处理这种负载。

您可以考虑一些替代方案：

如果您想在每个构建上强制使用干净的本地存储库，您可以使用清除依赖插件的目标。
如果您想保持构建隔离，可以通过传递 -Dorg.apache.maven.global-settings=/path/to/global/settings.xml 使用单独的 Maven 设置。
或者，您可以在每个构建的基础上覆盖本地存储库：传递 -Dmaven.repo.local=/some/repo/path
如果您想避免在每次构建时访问远程存储库，请添加never到您的远程存储库配置。这意味着 Maven 仅在您在命令行上使用“-U”开关强制执行时才会检查更新。
如果您想获取依赖项的最新版本，您可以在版本声明中使用 LATEST 关键字（而不是版本号），但如果依赖项不兼容，这可能会存在风险。
如果要获取依赖项的当前发行版本，可以在版本声明中使用 RELEASE 关键字（而不是版本号）。这类似于最新版本，但往往是最新的稳定版本，而不是最新版本。
如果要获取某个范围内依赖项的最新版本，请使用 Maven 的版本范围表示法，例如 [1.0.0,2.0.0) 表示从 1.0.0（含）到 2.0.0（不含）的任何版本

有关 LATEST 的更多详细信息和发布，请参阅 Maven 书的第 9.3.1.3 节。

如果您使用内部存储库管理器（必需 Nexus 和 Artifactory 引用），清除本地存储库的开销大大减少 - 您将只是增加本地网络流量负载。

Having no local repository would mean your classpath consisting almost entirely of URLs on remote servers. I can't see why this would be supported as execution would be awful, and any dropped connection would result in classloader issues. Having a local repository ensures the jars are available before compilation/execution begins.

Also consider that WAR and EAR projects (and many using the dependency plugin) rely on downloading the jars to complete their packaging. There would be a huge overhead if these had to be retrieved from a remote repository on every build. I'm pretty sure the managers of central would not be keen on dealing with that load.

Some alternatives for you to consider:

If you want to force a clean local repository on each build, you can use the purge goal of the dependency plugin.
If you want to keep builds isolated, you can use separate Maven settings by passing -Dorg.apache.maven.global-settings=/path/to/global/settings.xml
Alternatively you can override the local repository on a per build basis by passing -Dmaven.repo.local=/some/repo/path
If you want to avoid hitting remote repositories on each build, add <updatePolicy>never</updatePolicy> to your remote repository configurations. This means Maven will only check for updates if you force it to with a "-U" switch on the command line
If you want to take the latest version of a dependency, you can use the LATEST keyword in the version declaration (instead of the version number), though this can be risky if the dependency is incompatible.
If you want to take the current release version of a dependency, you can use the RELEASE keyword in the version declaration (instead of the version number). This is like LATEST, but tends to be the newest stable build, rather than the newest.
If you want to take the latest version of a dependency within a range, use Maven's version range notation, for example [1.0.0,2.0.0) means any version from 1.0.0 inclusive to 2.0.0 exclusive

For more details on LATEST and RELEASE, see section 9.3.1.3 of the Maven book.

If you use an internal repository manager (obligatory Nexus and Artifactory references here), the overhead of purging the local repository is greatly reduced - you'll just have an increased local network traffic load.

回复收藏 0 原文

~没有更多了~