首先，我从C#回到Java，所以如果我的术语或哲学不太一致，请道歉。
背景是这样的：我们有越来越多的为网络编写的内部支持工具。他们使用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设计，从长远来看，这将是一件好事。
- 它还可能为您提供源代码控制的正确粒度 - 即您的开发人员可以单独检查和处理特定的应用程序或后端模块
如果一个项目的某个部分可能用于多个项目，那么将其拉出是有意义的。如果您需要更新常用项目中的代码，它也会使其更干净一些。
如果你把它们放在一起，你在开发、构建和部署工具时遇到的障碍就会减少。
我们遇到了相反的情况，有许多单独的项目。将它们合并到一个项目树中后，我们的工作效率要高得多，这对我们来说比任何碰巧流行的约定都更重要。