最好的 jar 组织策略是什么？
如果我们正在构建一个大型的 java 类库，什么决定了何时最好将它们分割成单独的 jar 文件？
我的理解是，拥有一个大的 jar 文件不应显着影响 JVM 性能。然而，如果在对 jar 进行更改或添加时运行一整套冗长的测试，则会产生一些开发成本。在 maven 和 archiva 中使用大型 jar 文件是否有成本或好处？
人们在实践中使用什么策略？
If we are building a large library of java classes, what determines when it is best to split them into separate jar files?
My understanding is that having one large jar file should not significantly affect the JVM performance. However, there is some development cost if an entire suite of lengthy tests are run when changes or additions are made to the jar. Is there a cost or benefit when using large jar files with maven and archiva?
What strategy do people use in practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
仅考虑变更管理方面，其余的可以忽略不计。 Jar 文件决定了最小可释放单元。
Take into account change management aspects only, the rest is negligible. Jar file is something that determines minimum easily-releasable unit.
我们喜欢将罐子分成更小、更易于管理的单元。每个 jar 都专门用于执行一部分任务。当我们开发一个应用程序时，我们只会将其需要的罐子拉入其中，而不是一个包含所有内容的大罐子。
我们有用于安全性、UI、通用结构和界面、本地化以及许多其他特定于我们行业的东西的 jar。
We like to split our jars up into smaller, more manageable units. Each jar is specific for doing a subset of tasks. When we develop an application, we'll pull into it only the jars it needs, rather than one large jar that has everything.
We have jars for security, UI, general structures and interfaces, localization, and a bunch of other things that are specific for our industry.
jar项目在逻辑上是分开的，没有循环依赖，一层只依赖于前面的层。
由于您可以（除了项目名称）给出 IDE 中列出的描述性名称，保持项目有序的一种方法是使用缩写和数字前缀：
Logically separate layers of jar projects, without cyclic dependencies, one layer only depending on preceding layers.
As you can (besides the project name) give a descriptive name being listed in the IDE, one way to keep projects ordered is with abbreviation and numeric prefix: