java中的包与项目分离

首先，我将从C#回到Java，如果我的术语或哲学不太一致，我深表歉意

以下是背景：我们有越来越多的为web编写的内部支持工具。他们在前端使用HTML5/AJAX/其他流行语，在后端使用Java。这些工具利用了一个轻量级的内部框架，因此它们可以共享一个用于安全和其他配置的管理界面。每个工具都是由一位独立的作者编写的，我希望这种趋势会继续下去，因此我希望未来的作者能够轻松地在我们已经决定用于DI、单元测试、ORM等的第三方库上保持“标准化”

我们的包命名当前如下所示：

• com.ourcompany.tools.framework
• com.ourcompany.tools.apps.app1name
• com.ourcompany.tools.apps.app2name

……等等

所以我的问题是：对于Maven设置、Eclipse等，这些应用程序（和框架）是否应该被视为一个单独的项目

随着时间的推移，我们可能会有很多应用程序出现在这里，因此，分离似乎可以使依赖关系更清晰，并让用户更容易地使用单个工具。另一方面，（1）可能在多个项目上“拆分”包结构的较深部分是一种代码味道，（2）保持它们的组合将使工具编写者更倾向于使用其他工具已有的第三方库

FWIW，我最初的直觉是把它们分开

---

你说呢，Java大师？

我绝对会把他们分开。对于Maven来说，确保每个应用程序/项目都与框架/应用程序具有适当的依赖关系，这样当您只想构建一个应用程序时，就不必构建所有内容。

如果一个项目中有一个部分可能用于多个项目，那么将其拔出是有意义的。如果您需要更新其中一个常用项目中的代码，这也会使它更干净。

我将项目分开，但使用父pom包含所有依赖项和其他公共属性。单个工具/项目具有父项目的名称和引用，以及任何特定于项目的依赖项（如果有的话）。这有助于保持公共库和依赖项，因为公共库和依赖项已经全部配置好了，但允许我将重点放在需要使用的代码库的特定部分。

我肯定会将此类内容分离到单独的项目中

您应该使用Maven自动处理依赖项/构建过程（对于您自己的内部共享库和第三方依赖项）。让多个应用程序引用相同的共享库不会有任何问题-如果需要，您甚至可以保留多个版本

这种方法带来的几点好处：

• 这迫使您仔细考虑共享项目的API设计，从长远来看，这将是一件好事
• 它还可能为您提供正确的源代码控制粒度，即您的开发人员可以单独检查并处理特定的应用程序或后端模块

---

如果将它们放在一起，开发、构建和部署工具的障碍就会减少

---

我们的情况正好相反，有许多独立的项目。在将它们合并到一个项目树中之后，我们的工作效率要高得多，这对我们来说比任何惯例都更重要。

在您提到之前，我不知道依赖关系处理的父pom概念。我真的很喜欢这个加强应用程序标准化的想法。其他答案也很好，但家长的pom给了这一个优势。谢谢