我想你们大多数人都会知道，程序员经常重用其他软件的代码。我认为，大多数时候这是一个好主意。但是如果你使用来自另一个项目的代码，你的程序依赖于另一个项目。
我目前的案例我有三个java项目A，B和C。现在A使用B，B使用C。我正在使用eclipse IDE并将B添加到A的构建路径和C的构建路径到B的构建路径。现在有一个A 无法从 C 中解析某些内容的编译器错误。所以我必须将 C 添加到 B 的构建路径中。
那么，解决依赖关系的最佳方法是什么，同时使您的程序尽可能独立于其他项目呢？
我想知道的是一般情况，并参考我目前的情况。有没有更好的方法来做到这一点？即在启动/调试配置视图中有类路径设置，但我认为它们在编译时无济于事。
提前致谢。
这听起来像是 Maven 解决的问题的一部分。使用 Maven 和 Eclipse，即 m2eclipse，您可以让项目使用其他项目，并为您处理所有依赖项解析。
在我看来，你正在做你必须做的事情，而没有结合像 Ivy 或 Maven 这样的依赖管理工具，它们为你提供了“传递依赖管理”的能力。使用这些工具中的任何一个，您都可以指定 A 依赖于 B，B 依赖于 C，它们会自动知道 A 也将需要 C。
当需要打包项目以进行部署时，Maven 的优势（这是我所拥有的经验）也会发挥作用，因为它可以轻松收集所有这些依赖项（一直到层次结构）并将它们一起放入分发中文件夹或包含所有依赖项的胖 JAR。进入像 Maven 这样的工具需要一些阅读和设置时间，但它确实使管理依赖项的任务变得更加容易，尤其是随着它们的增长。
我们使用 Maven，它对我们的项目至关重要。这是您学习的好时机 - 对超过 3 个项目的依赖可能会令人恐惧。Maven 处理版本，因此如果出于某种原因您必须依赖 Foo.1.2.3，那么 Maven 将确保您不会得到错误的版本。
然而，这不是微不足道的。如果您使用 Netbeans，它的内置功能比 Eclipse 更好，并且可以帮助您学习。（此外，项目在两个系统之间是相当可切换的）。
Maven 在其 POM (pom.xml) 文件中支持很多概念，包括许可证信息、贡献者、参数等，因此您获得的不仅仅是依赖管理。它支持项目的模块化。
不要跳过学习曲线——你需要知道它是如何工作的。但是您还会发现以前的 SO 问题会有所帮助
其他人提到了几个很好的工具，maven 可能是最常见的。Ivy 是另一个更针对依赖管理的。我个人使用 gradle，它在熟悉的 groovy 包装器下具有所有这些功能中最好的一些……它仍在不断发展，并且记录不完整。;)
需要注意的一件事是这些工具如何处理传递依赖关系。在您的示例中，C 是 A 的传递依赖项，因为 A 依赖于 B，而 B 又依赖于 C。其中一些构建工具将以不同的方式处理这种类型的依赖项，并且在您最不期望的时候它会让您感到惊讶。
例如，如果 A 实际上是指来自 C 的代码，即：它对 C 具有编译时依赖性，那么您的 A->B->C 设置将在 Maven 之类的东西中工作。另一方面，gradle 也会让你声明 A 依赖于 C...，因为它确实如此。无论哪种方式，运行时依赖项都已完全解决。
当您几个月来一直在传递包含某些内容并且您的一些代码依赖于 C 的各个方面并且您决定不再需要 B 依赖项时，您会感到惊讶。突然之间，在您确定需要指定 A->C 依赖项之前，您的代码不会构建。在此示例中，这很容易发现，但有时并非如此。
如果这样的谈话让你有点头晕，并且你不打算让你的项目变得更加复杂......那么你可能只是坚持你正在做的事情一段时间。正如其他人所提到的，在没有工具帮助您的情况下，这是正确的方法。
使用 maven 管理您的依赖项，然后使用依赖项插件查看依赖项。
你可以跑
mvn 依赖：分析
或者
mvn 依赖：树 -Dverbose=true
这会对你有很大帮助。
毫无疑问，您应该使用人们已经注意到的依赖管理工具……但是，手动将 B 和 C 归档到 B_C.jar 中。测试 B 对 C 的依赖是否在 Jar 中得到解决。
然后在类路径中添加 B_C.jar ...
依赖管理是一个巨大的话题。已经开发了 Maven、Ivy 和其他工具来减轻痛苦并取得了一些成功。这两个工具都创建了一个依赖层次结构，因此您不会遇到您描述的情况。它们还具有 Eclipse 插件，以便 Eclipse 能够识别该层次结构。
要真正使用这些框架，您必须更改当前的构建过程。Maven 可能比 Ivy 需要更多的承诺，但两者都不是微不足道的，理解如何设置它需要一些时间。也就是说，清楚地定义和管理您的依赖关系是非常有帮助的。
免费的 Maven 书籍：