扩展/继承Tomcat项目

Question

我们正在使用Eclipse + Tomcat插件开发webapps。我们最近开始推出一款新的应用程序，该应用程序将在Facebook和StudiVZ（德国的FB竞争对手）上运行。由于应用程序的功能将是95％相同，我们将代码拆分为单独的Eclipse项目（app-core，app-facebook，app-vz）。 -core项目源代码链接到Eclipse中的-facebook和-vz项目。我们还使用Hudson进行CI，并制作了在构建之前从-core项目导入代码的ant脚本。所以基本上我们试图在项目层面上继承。

所述方法存在一些缺陷：

• 版本控制很复杂
• -core项目不会独立运行，这使得自动测试部分不可能
• 我们需要修改-core项目类依赖的一些模型
• 让我觉得这不是最佳解决方案的其他问题

有没有人建议更好的解决方案？

Answer 1

有大量可用于Java的构建工具，专门用于依赖管理和版本控制。其中许多与Hudson和Eclipse集成在一起。

我建议查看Maven以及它如何将依赖关系管理作为一个很好的起点。即使您不使用Maven本身，许多解决方案都基于Maven的依赖关系管理机制。像Apache Ivy这样的东西允许你使用maven依赖管理，但仍然使用你自己的自定义Ant脚本;而Gradle之类的东西是批发替代品。

Answer 2

您应该能够将项目拆分为3个或更多部分，然后通过Java Build Path建立依赖关系。您需要清理项目之间的依赖关系。如果您需要根据它是-facebook还是-vz项目来配置核心组件，您可能需要单独配置，甚至可能使用Spring或类似的依赖注入框架。

当尝试将重用引入基于Web的Java项目时，通常会在UI代码中出现问题。考虑到这种方法，构建的框架并不多。

Answer 3

我不使用/讨厌Eclipse [1]，但可以指出我们如何处理类似的问题。

我们使用Maven和IntelliJ。特别是，这两个都支持已定义内部依赖关系的modules。在您的情况下，它可能是 -fb 和 -vz 模块，具体取决于核心，或者您可以将核心拆分为更小的部分（例如 DAO ，业务逻辑等。）。

编译时，“上层”模块的可交付成果将用于构建“下层”模块。

让我们回顾你提出的观点/缺陷：

• 版本控制不再是问题，因为所有内容都位于您选择的Subversion / GIT / VCS的相同根目录下
• 为什么会出现这个问题？当然，这不应该是单元测试的问题，因为我理解TDD，这些不应该需要复杂的环境。对于自动化测试，您必须测试核心API（因为这是核心与其他所有内容之间的接口，对吧？）因此这不应该需要任何前端的东西吗？

• 你需要解释你的其他观点，告诉你为什么不喜欢它

  1. 要求开发人员使用除他/她选择的IDE以外的任何东西，这是针对日内瓦会议的。