Java 分发为包含配置、库和 deps 的 jar 文件
我正在开发一个需要很多东西才能工作的框架。我的 Eclipse 项目中有几个需要的文件夹
[root]
- 配置
- 源代码
- 库
- 序列化
此外，src 目录中还有一些重要文件，例如 log4j.properties 和 META-INF 目录。
我想知道是否有一种方法可以分发一个包含所有基本文件的 JAR，这样我的 gui 只需要导入一个 jar。我想我必须排除 config 文件夹才能使框架可配置。
我还想知道，是否有一种方法可以将 log4j.properties 移动到 config 目录，以便我有一个配置文件夹包含所有需要的配置？
感谢您对此事的帮助和建议！
马可
I am developing a framework that needs a lot of stuff to get working. I have several folders inside of my Eclipse project that are needed
[root]
- config
- src
- lib
- serialized
Also there are important files like the log4j.properties and the META-INF dir inside the src directory.
I wonder if there is a way to distribute one JAR containing all essential files so my gui will just have to import one jar. I guess that I have to exclude the config folder in order to make the framework configurable.
I also wonder, if there is a way to move for example the log4j.properties to the config dir so that I have one config folder containg all needed configurations?
Thanks for help and advise on this matter!
Marco
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，但不是真的。您可以获取所有依赖项，将它们解压并简单地将它们合并到一个更大的 jar 中。如果你制作一个带有依赖项的 jar，这就是 Maven jar 插件所做的事情。唯一的问题是这可能会导致文件冲突（假设您的两个依赖项包含 log4j.properties）。例如，当使用某些 spring 库执行上述操作时，这是问题之一。
我认为有人实际上编写了一个类加载器，它允许您将整个 jar 捆绑在 jar 中并按原样使用它。我不确定它有多成熟，但目前记不起这个名字。
我认为你最好单独分发所有依赖项。设置类路径有点麻烦，但 Java 程序员现在肯定已经习惯了。您可以将依赖项添加到清单文件中的 Class-Path 标头，在简单的情况下。不过，更大的库必须依赖于为它们设置的类路径。
至于问题的第二部分，可能将 conf/ 目录放在 META-INF 下就足以获取其内容。我对此不太确定。我相当确定，如果您将其内容物放在罐子的顶层，它总是会被拾起。无论如何，这是一个分配问题。您可以轻松地在源代码树中创建一个
conf/目录，并让您的构建脚本（无论您使用什么）将其中的文件复制到最方便的位置。至于您的用户配置。尝试建立一些约定，以便他们必须尽可能少地进行配置。对于必须配置的东西，最好有一个基本的默认配置，然后允许用户通过他/她自己的配置文件覆盖和添加选项。
Yes, but not really. You can take all your dependencies, unpack them and simply merge them into a bigger jar. This is what the maven jar plugin does if you make a jar with dependencies. The only problem is that this might result in conflicting files (suppose two of your dependencies contain a log4j.properties). This is one of the problems when doing the above with some of the spring libraries for instance.
I think someone actually wrote a classloader that allows you to bundle the whole jar inside of your jar and use it as is. I'm not sure how mature that is though and can't at the moment recall the name.
I think you're better off distributing all your dependencies separately. Setting up the classpath is a bit of a pain but surely java programmers are used to it by now. You can add dependencies to the Class-Path header in your manifest file, in simple cases. Bigger libraries have to rely on the classpath being set up for them though.
As to the second part of your question, probably dropping the conf/ directory under META-INF is enough for its contents to be picked up. I'm not sure about this. I'm fairly sure it will always be picked up if you put its contents at the top level of the jar. In any case, this is a distribution problem. You can easily have a
conf/directory inside your source tree and have your build scripts (whatever you might be using) copy the files in it to wherever is most convenient.As to your users configuring. Try to establish some conventions so they have to configure as little as possible. For things that must be configured, it's best to have a basic default configuration and then allow the user to override and add options through his/her own configuration file.
就资源而言，这是可能的，除非您这样做，否则您将无法从文件系统（通过文件路径）加载资源（非类文件）。
您当前可能正在从文件系统加载这些资源。进入 jar 后，您需要通过 class.getResourceAsStream 或类似方法将它们加载为类路径资源。
至于您可能拥有的依赖 jar，通常的做法是将它们作为额外的 jar 放置在类路径上。我知道这会让事情变得复杂，但开发人员已经习惯这样做了。 java 景观的本质是这是不可避免的。例如，spring 框架的作用是提供一个捆绑的 zip 文件，其中包含核心 jar 和包含的 jar 依赖项。
您的库将用于 EE 环境还是 SE 环境？如果它是 EE 上下文，那么您实际上不必担心配置和类路径问题，因为容器会处理这些问题。在 SE 环境中，这要棘手得多，因为该工作必须手动完成。
In terms of the resources, it is possible except that if you do that you are not going to be able to load resources (non class files) from the filesystem (via a file path).
It's likely that you're currently loading these resources from the file system. Once in the jar you need to load them as class path resources via the class.getResourceAsStream or similar.
As for the dependent jars you may have, it's common practice for these to be placed as extra jars on the classpath. I know it's complicates things but developers are used to doing this. The nature of the java landscape is that this is inevitable. What the spring framework for example does is supply a bundled zip file with the core jar and the jar dependencies included.
Is your library going to be used in an EE context or an SE context? If it is an EE context then you really don't have to worry about configuration and class path issues as the container takes care of that. In an SE context it is a lot more tricky as that work has to be done manually.