管理 maven 依赖项 - 新版本和非回购库

Managing maven dependancies - New Versions and Non-Repo libraries(管理 maven 依赖项 - 新版本和非回购库)

问题描述

警告:我刚刚学习了 Maven，所以提到的内容可能是错误的或不是最佳实践.

Warning: I have just picked up Maven, so things mentioned might be wrong or not best practice.

我有一个中等规模的开源项目，我正在从基础迁移到 MavenNetBeans 项目管理.这不是一个开发团队共享同一个房间，这是 1-5 个人在互联网上共享一个 SVN 存储库.阅读有关依赖项的操作方法，似乎获取依赖项的唯一方法是从在线存储库获取它们或在本地安装它们.

I have a medium size open source project that I am migrating to Maven from the basic NetBeans project management. This is not a developer team sharing the same room, this is 1-5 people over the internet sharing a SVN repo. Reading over the how-tos on dependencies, it seems that the only way to get dependencies is to get them from an online repo or install them locally.

这不是我想要的.出于多种原因，我想将所有依赖项保留在 SVN 中，包括可移植性(任何人都可以通过，检查 repo，构建和使用；所有这些都无需手动添加到本地 repo 等)，获得更新的版本(下面讨论)，以及手动版本控制.

This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons including portability (anybody can pass by, check out the repo, build, and use; all that simply without manual adding to local repo's and whatnot), getting newer versions (discussed below), and manual versioning.

我对 maven 存储库的另一个问题是它们的版本相当落后.例如，Logback 是 0.9.18 在 mvnbrowser 但 0.9.24 正式.PircBot 在 mvnbrowser 中是 1.4.6 但 1.5.0 正式版.为什么会有这么旧的版本?

The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?

问题 3 是我的依赖项甚至在 repos 中都不存在，例如 Easier Java Persistence.

Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.

所以

1. 如何强制所有依赖项来自 /lib 例如
2. 在相关说明中，mvn 可以直接从库的 SVN 存储库构建吗?只是好奇
3. 如果他们也使用 Maven，是否有一种自动方法可以直接从依赖项站点/svn repo 获取最新版本?IE 库，例如 commons-lang 或 logback
4. 有没有更好的方法来管理依赖关系?(IE Ivy 或我缺少的一些奇怪的 POM 选项)

仅供参考，这是一个具有 3 个模块、项目全局依赖项和模块特定依赖项的 Java 项目.

FYI, this is a Java project with 3 modules, project global dependencies and module specific dependencies.

如果它可以与 NetBeans 附带的捆绑版本的 Maven 一起使用，则可以加分.

Bonus points if it can work with the bundled version of Maven that comes with NetBeans.

不重复

• Maven:添加依赖项通过相对路径到 jar - 不想安装到本地存储库
• maven 编译失败，因为我有一个非maven jar - 不要认为系统依赖是正确的答案
• maven 寻找新版本的依赖项 - 仍然使用(?) 存储库，只是最新(旧)版本

• Maven: add a dependency to a jar by relative path - Not wanting to install to local repository
• maven compile fails because i have a non-maven jar - Don't think a System dependency is the right answer
• maven look for new versions of dependencies - Still uses(?) repository, just the latest (old) version

推荐答案

这不是我想要的.出于多种原因，我想将所有依赖项保留在 SVN 中 (...)

This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons (...)

我会回来讨论这个问题，但我在 Maven:通过相对路径向 jar 添加依赖项(使用基于文件的存储库)允许实现这样的解决方案.

I will come back on this but the solution I described in Maven: add a dependency to a jar by relative path (using a file-based repository) allows to implement such a solution.

我对 maven 存储库的另一个问题是它们的版本相当落后.例如，mvnbrowser 中的 Logback 是 0.9.18，但官方是 0.9.24.PircBot 在 mvnbrowser 中是 1.4.6，但官方是 1.5.0.为什么会有这么旧的版本?

The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?

看起来 mvnbrowser 索引完全过时(使其无用作为存储库搜索引擎)因为 maven 中央存储库确实有 logback-core-0.9.24.jar (logback 项目正在做必须做的事情来实现这一点)但只有一个旧的 pircbot-1.4.2.jar.为什么?询问 pircbot 团队.无论如何，你是对的，中央存储库可能并不总是有最终版本.

It looks like mvnbrowser indices are totally out of date (making it useless as repository search engine) because the maven central repository does have logback-core-0.9.24.jar (the logback project is doing what has to be done to make this happen) but only has an old pircbot-1.4.2.jar. Why? Ask the pircbot team. Anyway, you're right, the central repository might not always have ultimate versions.

问题 3 是我的依赖项甚至在 repos 中都不存在，例如 Easier Java Persistence.

Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.

是的，这也会发生.

例如，我如何强制所有依赖项来自/lib

How can I force all dependencies to come from /lib for example

如前所述，您应该仔细阅读 Maven:通过相对路径向 jar 添加依赖.此解决方案不是关于将库安装到本地存储库，而是关于使用基于文件的存储库(因此可以存储在 SVN 中).您可能错过了重点，这符合您的用例.并检查 Brett 的回答 变体.

As previously hinted, you should re-read carefully the solution suggested in Maven: add a dependency to a jar by relative path. This solution is not about installing libraries to the local repository but is about using a file-based repository (that could thus be stored in SVN). You might have missed the point, this matches your use case. And also check Brett's answer for a variation.

在相关说明中，mvn 可以直接从库的 SVN 存储库构建吗?只是好奇

On a related note, can mvn build from library's SVN repo directly? Just curious

没有得到那个.你能澄清一下吗?

Didn't get that one. Can you clarify?

如果他们也使用 Maven，是否有一种自动方法可以直接从依赖站点/svn repo 获取最新版本?IE 库，例如 commons-lang 或 logback

Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback

Maven 支持 版本范围 并且您可以使用允许使用任何大于 X 的版本"的语法.但为了构建可重复性，我确实不建议使用版本范围.您不希望构建由于发生在您背后的一些自动更新而突然失败.仅当您需要错误修复或新功能时才升级，但要明确进行(如果没有损坏，请不要修复它).

Maven supports version ranges and you could use a syntax allowing to use "any version greater than X". But I do NOT recommend using version ranges at all, for the sake of build reproducibility. You don't want the build to suddenly fail because of some automatic update that happened on your back. Only upgrade if you need bug fixes or new features, but do it explicitly (if it ain't broke, don't fix it).

您可能还会发现 提及 LATEST 和 RELEASE 版本标记.出于与上述相同的原因，我不推荐它们，甚至更少，因为 它们已从 Maven 3.x 中删除.

You might also find mentions of the LATEST and RELEASE version markers. I don't recommend them neither for the same reasons as above and even less since they're removed from Maven 3.x.

有没有更好的方法来管理依赖关系?(IE Ivy 或我缺少的一些奇怪的 POM 选项)

Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)

不能说常春藤.但是在 Maven 领域，如果您无法为您的项目(Nexus、Archiva、Artifactory)托管企业"存储库，那么基于文件的存储库是 IMO 的最佳方法.

Can't say for Ivy. But in the Maven land, if you can't host up a "corporate" repository for your project (Nexus, Archiva, Artifactory), then the file-based repository is IMO the best approach.

这篇关于管理 maven 依赖项 - 新版本和非回购库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！