最佳常春藤实践：将代码拆分为多个项目或使用具有多种配置的一个项目？
在工作中，我们有许多项目需要共享一些通用代码。有些代码是完全通用的，而有些代码仅由我们项目的子集共享。我应该将公共代码拆分为两个单独的项目还是为单个项目使用两种不同的 ivy 配置？
选项 1 - 两个独立的项目。
- Proj 1 - Common 作为默认配置发布
- Proj 1 - Common-xml 作为默认配置发布
潜在问题： 要求我有两个单独的项目，具有两个单独的构建文件和两个单独的 ivy 文件。
选项 2 - 一个项目，不同工件的多个 ivy 配置
- 工件 1 - 共同发布为核心
- 工件 2 - 共同 xml 发布为 core-xml
潜在问题：我可能必须在同一目录中维护单独的源目录项目。
在任一情况下，公共 xml 组件都可以依赖于公共核心组件。
那么，SF，我应该如何维护我的公共代码呢？这两种方法我错过了哪些问题，还有哪些其他优点/缺点或替代解决方案？
At work we have a number of projects which need to share some common code. Some code is completely universal while some of the code is only shared by a subset of our projects. Should I split up the common code into two separate projects or use two different ivy configurations for a single project?
Option 1 - Two separate projects.
- Proj 1 - Common published as default configuration
- Proj 1 - Common-xml published as default configuration
Potential Issues: Requires that I have two separate projects, with two separate build files and two separate ivy files.
Option 2 - One project, multiple ivy configurations for different artifacts
- Artifact 1 - Common published as core
- Artifact 2 - Common xml published as core-xml
Potential Issues: I may have to maintain separate source directories in the same project.
In either case, the common xml component may rely on the common core component.
So, SF, what should I do for maintaining my common code? What issues did I miss with the two methods, and what are any other pros/cons or alternative solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，这实际上取决于您喜欢如何管理源代码。但首先，我会问你是否真的需要拆分源代码。公共项目的想法是封装可以被其他项目用作通用工具包的代码、类、接口等。这并不意味着这些项目必须使用 Commons 中的所有内容。他们可能只使用其中的一小部分。这完全没问题，但分割你的共享资源可能实际上是过度优化。
想一想 - 如果您的下一个项目使用 Commons 库的不同子集会发生什么？你们又要分手吗？
Hmm, it really comes down to how you prefer to manage your source code. But first, I'd be asking the question of whether you really need to split the source. The idea of a commons project is to encapsulate code, classes, interfaces, etc that can be used as a common toolkit by other projects. It doesn't mean those projects have to use everything in Commons. They might only use a small portion of it. That's perfectly fine and it might be that splitting your Commons is effectively over optimisation.
Think of this - what happens if your next project uses a different subset of the Commons library? are you going to split again?