eclipse，一个用于编译的类路径，另一个用于启动
示例：
对于日志记录，我的代码使用 log4j。但我的代码依赖的其他 jar 则使用 slf4j 代替。所以这两个 jar 必须位于构建路径中。不幸的是，我的代码现在可以直接使用（依赖）slf4j，无论是通过上下文辅助，还是其他一些开发人员进行更改。我希望 slf4j 的任何使用都显示为错误，但我的应用程序（和测试）在运行时仍然需要在类路径中使用它。
说明：
我想知道这在日食中是否可行。这种场景在我身上经常发生。我将有一个大型项目，其中使用大量第三方库。当然，那些 3rd 方 jar 也有自己的依赖项。因此，我必须在类路径（Eclipse 中的“构建路径”）中包含应用程序及其要编译和运行的测试（从 Eclipse 内）的所有依赖项。
但我不希望我的代码使用所有这些 jar，而只希望我自己决定的几个直接依赖项。因此，如果我的代码不小心使用了依赖项的依赖项，我希望它显示为编译错误。理想情况下，因为找不到类，但任何错误都会发生。
我知道我可以在 Eclipse 外部运行时手动配置类路径，甚至在 Eclipse 内我也可以修改我正在运行的特定类的类路径（在运行配置中），但如果您运行大量单独的测试用例，则这是不可管理的，或者有很多 main() 类。
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
听起来您的项目有足够的依赖关系，您可能会考虑使用 OSGi 捆绑包（插件）来构建它。每个包都有自己的类加载器，并指定它所依赖的包（以及可选的版本范围等）、导出哪些包、是否从其依赖项中重新导出内容等。Eclipse
本身是由 Eclipse 构建的插件和片段，它们只是 OSGi 捆绑包，附加了可选的少量附加 Eclipse 接线（
plugin.xml，用于声明 Eclipse“扩展点”和“扩展”）。因此，Eclipse 具有相当好的工具来创建和管理内置捆绑包（通过插件开发环境）。您在那里发现的大部分内容可能会导致您将“OSGi 包”与“扩展 Eclipse IDE 的插件”混为一谈，但这两个概念是完全分开的。Eclipse 工具确实相当清楚地区分了构建环境中的捆绑包与特定运行配置包含的捆绑包（有时令人烦恼，但以“有用的药物”方式）。
在 OSGi 领域生活了几年之后，默认的 Java“扁平类路径”对我来说感觉很奇怪，甚至有点破碎，很大程度上是因为（正如您所经历的）它将所有 JAR 扔进一个巨大的竞技场，并希望它们能够解决问题。 OSGi 环境使我能够更好地控制依赖关系，并且作为“副作用”自然也需要澄清这些关系。在这些明确的声明和工具的执行之间，项目的结构对于团队中的每个人来说都更加明显。
将您的代码放在一个插件中，将您的直接依赖项放在其他插件中，将它们在其他插件中的依赖项等等，并声明每个插件的依赖项。 Eclipse 将立即执行您想要的操作。自动完成功能中不会向您提供依赖项的依赖项内容；你会得到红色波浪线和构建错误； ETC。
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (
plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
为什么不使用访问规则来保持代码整洁？
Why not use access rules to keep your code clean?
看起来最好用maven管理，与m2eclipse集成在eclipse中。
这样，您只能执行 Maven 构建生命周期的一部分，并且可以管理每个构建步骤的一组单独的依赖项。
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
根据我的经验，限制性更强是有帮助的，我让团队填写（纸质）表格，为什么需要这个罐子以及什么许可证……
他们宁愿输入几行代码，而不是拖着 20 个罐子来打开仅使用一行代码或另一个奇特的“功能”的文件。
使用 Maven 可能会有所帮助，但是当您第一次发现具有诸如 nightly-build 或 snapshot 之类名称的 jar 时，您就会知道自己正处于 jar-hell 中。
结论：选择好依赖关系
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
使用 slf4j-over-log4j jar 有用吗？这允许使用 slf4j 并将实际日志记录转至 log4j。
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.