解决 Java 项目之间依赖关系的最佳方法是什么?

发布于 2024-08-15 13:35:12 字数 356 浏览 4 评论 0原文

我想你们大多数人都会知道,程序员经常重用其他软件的代码。我认为,大多数时候这是一个好主意。但是,如果您使用另一个项目的代码,您的程序将依赖于另一个项目。

我当前的情况是,我得到了三个java项目A、B和C。现在A使用B,B使用C。我正在使用Eclipse IDE,并将B添加到A的构建路径中,将C添加到B的构建路径中。现在有一个编译器错误,A 无法解析 C 中的某些内容。所以我必须将 C 添加到 B 的构建路径中。

那么,解决依赖关系同时保持程序尽可能独立于其他项目的最佳方法是什么?

我想知道的是一般情况并参考我目前的情况。有更好的方法来做到这一点吗?即启动/调试配置视图中有类路径设置,但我认为它们在编译时没有帮助。

提前致谢。

I think most of you will know, programmers often reuse code from other software. I think, most of the time it is a good idea. But if you use code from another project your program depends on the other project.

I my current case I got three java projects A, B and C. Now A uses B and B uses C. I'm using eclipse IDE and added B to the buildpath of A and C to the buildpath of B. Now there is an compiler error that A can't resolve something from C. So I have to add C to the buildpath of B.

So what is the best way, to resolve the dependencies while keeping your programm as independent as possible from other projects?

I would like to know is in general and in reference to my current situation. Are there better ways to do this? I.e. there are classpath settings in the launch / debug configuration view, but I think they won't help at compile time.

Thanks in advance.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(8

ぽ尐不点ル 2024-08-22 13:35:12

这听起来像是 Maven 解决的问题集的一部分。使用 Maven 和 Eclipse(即 m2eclipse),您可以让项目使用其他项目,并且所有依赖项解析都会为您处理。

This sounds like part of the problem set fixed by Maven. Using Maven and Eclipse, namely m2eclipse, you can have projects use other projects and all the dependency resolution is handled for you.

走过海棠暮 2024-08-22 13:35:12

在我看来,您正在做您必须做的事情,而没有合并像 Ivy 或 Maven 这样的依赖管理工具,它们为您提供了“传递依赖管理”的功能。使用这些工具中的任何一个,您都可以指定 A 依赖于 B,B 依赖于 C,它们会自动知道 A 也将需要 C。

当需要打包项目进行部署时,Maven 的优势(这是我的经验)也会发挥作用,因为它可以轻松收集所有这些依赖项(一直沿着层次结构)并将它们放在一起到一个发行版中文件夹或包含所有依赖项的 fat JAR。使用像 Maven 这样的工具需要一些阅读和设置时间,但它确实使管理依赖项的任务变得更加容易,尤其是随着依赖项的增长。

It sounds to me like you're doing what you have to without incorporating a dependency management tool like Ivy or Maven, which provide you the capability of "transitive dependency management". With either of these tools you can just specify that A depends on B and B depends on C and they will automatically know that A is going to need C as well.

The advantages of Maven (this is what I have experience in) also comes into play when it's time to package your projects for deployment since it can easily gather all of those dependencies (all the way down the hierarchy) and place them together into a distribution folder or a fat JAR that contains all of your dependencies. It takes some reading and set-up time to get into a tool like Maven, but it does make the task of managing your dependencies a whole lot easier, especially as they grow.

七月上 2024-08-22 13:35:12

我们使用 Maven,它对于我们的项目至关重要。现在是学习的好时机 - 对 3 个以上项目的依赖可能会令人恐惧。 Maven 处理版本,因此如果无论出于何种原因,您必须依赖 Foo.1.2.3,那么 Maven 将确保您不会获得错误的版本。

然而,这并不是一件小事。如果您使用 Netbeans,它的内置效果比 Eclipse 更好,并且可以帮助您学习。 (项目也可以在两个系统之间进行相当的切换)。

Maven 在其 POM (pom.xml) 文件中支持许多概念,包括许可证信息、贡献者、参数等,因此您获得的不仅仅是依赖项管理。它支持项目的模块化。

不要跳过学习曲线 - 您需要知道它是如何工作的。但你也会发现以前的SO问题会有所帮助

We use Maven and it's essential for our projects. It's a good time for you to learn - dependencies on more than 3 projects can be frightening. Maven deals with versions so that if, for whatever reason, you have to depend on Foo.1.2.3 then Maven will ensure you don't get the wrong version.

However it's not trivial. If you use Netbeans it's built in better than Eclipse and may help you learn. (Also projects are fairly switcheable between the two systems).

Maven supports a lot of concept in its POM (pom.xml) file including licence info, contributors, arguments, etc. so you get a lot more than just dependency management. And it supports modularisation of projects.

Don't skip the learning curve - you need to know how it works. But you will also find previous SO questions that will help

靖瑶 2024-08-22 13:35:12

其他人提到了一些好的工具,maven 可能是最常见的。 Ivy 是另一种更专注于依赖管理的工具。我个人使用 gradle,它在熟悉的 groovy 包装器下拥有所有这些功能中最好的一些......它仍在不断发展并且记录不完整。 ;)

需要注意的一件事是这些工具如何处理传递依赖关系。在您的示例中,C 是 A 的传递依赖项,因为 A 依赖于 B,而 B 又依赖于 C。其中一些构建工具将以不同的方式处理此类依赖项,并且可能会在您最意想不到的时候让您感到惊讶。

例如,如果 A 实际上引用了 C 中的代码,即:它对 C 具有编译时依赖性,那么您的 A->B->C 设置将在 Maven 之类的环境中工作。另一方面,gradle 也会让你声明 A 依赖于 C...因为它确实如此。无论哪种方式,运行时依赖性都得到完全解决。

当您几个月来一直在传递某些内容并且您的某些代码依赖于 C 的某些方面并且您决定不再需要 B 依赖项时,您会感到惊讶。突然之间,您的代码将无法构建,直到您发现需要指定 A->C 依赖项。在这个例子中,发现这一点非常简单,但有时却并非如此。

如果这样的谈话让你有点头晕,并且你不打算让你的项目变得更加复杂......那么你可能可以坚持你正在做的事情一段时间。正如其他人提到的,这是在没有工具帮助的情况下完成此操作的正确方法。

Others have mentioned several of the good tools, maven probably being the most common. Ivy is another one that is more targeted at just dependency management. I personally use gradle which has some of the best of all of those features underneath a familiar groovy wrapper... that is still evolving and spottily documented. ;)

One thing to be aware of is how these tools handle transitive dependencies. In your example, C is a transitive dependency of A because A depends on B which depends on C. Some of these build tools will handle this type of dependency differently and it can surprise you when you least expect it.

For example, if A actually refers to code from C, ie: it has a compile-time dependency on C, then your A->B->C setup will work in something like Maven. On the other end, gradle will also make you declare that A depends on C... since it does. Runtime dependencies are fully resolved either way.

The surprise comes when you've been transitively including something for months and some of your code has relied on aspects of C and you decide you no longer need a B dependency. Suddenly your code won't build until you figure out you need a A->C dependency specified. In this example, that's pretty trivial to discover but sometimes it isn't.

And if talk like that makes your head swim a little and you don't plan on your project getting much more complicated... then you can probably just stick with what you are doing for a while. As others mentioned, it's the right way to do it without a tool helping you.

泅渡 2024-08-22 13:35:12

使用 Maven 管理依赖项,然后使用依赖项插件查看依赖项。

您可以运行

mvn dependency:analyze

mvn dependency:tree -Dverbose=true

这会对您有很大帮助。

Use maven to manage your dependencies and then use the dependency plugin to see the dependencies.

you can run

mvn dependency:analyze

or

mvn dependency:tree -Dverbose=true

this will help you a lot.

萌能量女王 2024-08-22 13:35:12

毫无疑问,您应该使用依赖管理工具,正如人们所指出的那样...但是手动将 B 和 C 归档到 B_C.jar 中。测试 B 对 C 的依赖是否在 Jar 中得到解决。

然后在类路径中添加 B_C.jar ...

no doubt you should use a dependency management tool as people have noted... manually though, archive B and C in B_C.jar. Test that B's dependence on C is resolved within the Jar.

Then add B_C.jar in the classpath...

揽月 2024-08-22 13:35:12

依赖管理是一个很大的话题。 Maven、Ivy 和其他工具已经被开发出来以减轻痛苦并取得了一些成功。这两个工具都会创建依赖关系层次结构,因此您不会遇到您所描述的情况。他们还有 Eclipse 插件,以便 Eclipse 能够识别该层次结构。

要真正使用这些框架,您必须更改当前的构建过程。 Maven 可能比 Ivy 需要更多的承诺,但这两者都不是微不足道的,并且理解如何设置它需要一些时间。也就是说,明确定义和管理依赖项非常有帮助。

Dependency management is a huge topic. Maven, Ivy and other tools have been developed to ease the pain with some success. Both of those tools create a dependency hierarchy so you don't run into the situation you described. They also have Eclipse plugins so that Eclipse will recognize that hierarchy.

To truly use these frameworks, you will have to change your current build process. Maven probably requires more of a commitment than Ivy, but neither is trivial, and understanding how to set it up takes some time. That said, it is very helpful to have your dependencies defined and managed clearly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文