构建系统，允许在不同的二进制文件之间共享模块

我试图选择最合适的构建系统，以在具有公共源代码库的企业中工作，强调共享通用代码。我想源层次结构看起来是这样的：构建系统，允许在不同的二进制文件之间共享模块

 
- src 
    - java 
    - common 
     - net 
     - database 
    - team1 
    - team2 
    - team3 
     - lib 
- tests 
    - java 
    - common 
     - net 
     - database 
    - team1 
    - team2 
    - team3 
     - lib

的目标是有一个构建系统，其中团队[1-3]可以独立建立明确指定它们的依赖。看起来像依赖关系：

 
- team1 
    - common/net 
    - team3/lib 
- team2 
    - common/database 
- team3

因此，例如，建立TEAM1将包括TEAM1，普通/网，team3/lib目录内的一切;但没有别的。理想情况下，测试将以相同的方式进行集成（测试team1将运行team1，common/net和team3/lib的测试）。

我目前正在使用Ant，但还没有找到一种理智的方式来管理这样的层次结构。我开始考虑Maven 2管理依赖关系层次结构的能力，但它似乎需要为每个模块提供完整的项目。这不会是一个问题，但它似乎迫使我进入一个不能很好地映射到传统java包层次结构的目录结构。看起来，我可能能够使用alternative layout来使用buildr来做我想要的，但我担心这可能会变得脆弱。

有人可以推荐一些可能适合我的东西吗？

来源

2009-12-14 Bill

正如您所说，Maven 2是您的案例的首选选项。 Maven文件夹结构不是madnatory - 它是可配置，如果你认为它不可变。不过，我认为这是一个很好的结构，你可以无悔地遵循。

您可以使用repository manager，以便使用某些依赖关系的人不一定需要检出他们依赖的项目。

来源

2009-12-14 07:28:49 Bozho

我目前正在使用Ant，但还没有找到一种理智的方式来管理这样的层次结构。

这是令人惊讶的，因为Ant（+ Ivy？）为您提供了所有您想要的灵活性。

我开始关注Maven 2的管理依赖关系层次结构的能力，但它似乎希望为每个模块提供完整的项目。

如果通过这个你意味着每个模块一个pom.xml，那么这是正确的。

这不会是一个问题，但它似乎迫使我成为一个目录结构，没有很好地映射到传统的Java包层次结构。

是的，Maven带有一些约定，项目目录结构就是其中之一。这虽然（有点）是可配置的，但我认为你不能匹配想要的布局（将测试和源代码分隔开来）。其实，我强烈建议使用默认值，如果你使用Maven，你应该采用它的理念，它会为你节省很多，非常多的痛苦（甚至没有提到一些插件可能会使用这些默认值硬编码方式）。

说实话，我并不完全明白你的意思是目录结构不能很好地映射到传统的java包层次结构。首先，Maven非常适合Java，所以这对我来说没有任何意义。其次，这可能更主观，你的布局（单独的测试和源代码树）对我来说看起来并不传统。也许你应该清楚你的意思究竟是什么传统？

好像我也许可以做我想做的使用替代布局buildr，但我担心可能被证明是脆弱

我不太了解buildr，所以我不能多说，但我知道它确实更灵活。也就是说，如果Ant在灵活性方面不能让您满意，那么我不明白为什么buildr会更好。

不要忘记，与Maven相比，buildr和Ant + Ivy拥有更小的社区。不要低估这一点，这可能会成为一个真正的担忧。

就我个人而言，我会去Maven并重新考虑你的布局。但是让我们说我有偏见。

来源

2009-12-14 08:53:22

关键是我想支持在细粒度级别（与java包一样低）共享代码。因此，我希望模块的创建和细分尽可能无痛苦。关于'传统的java包层次结构'，我的意思是我想浏览版本库让你觉得你只是经历了一个巨大的java项目......实际上，构建系统只使用所需的部分每个版本。 – Bill 2009-12-14 10:14:05

Maven使模块的创建变得非常简单，但我不建议创建过细的模块，我不认为它真的有必要转到包级别。稍后我会更新我的答案以涵盖此。 – 2009-12-14 11:47:01

我开始关注Maven 2管理依赖关系层次结构的能力，但它似乎想要为每个模块提供完整的项目。

这是一种方法。或者，可以像这样组织一个多模块Maven项目：

project 
    module-1 
     src 
      main 
       .... 
      test 
       .... 
     pom.xml 
    module-2 
     src 
      main 
       .... 
      test 
       .... 
     pom.xml 
    ... 
    pom.xml

其中每个pom.xml也可以引用由其他树定义的模块。顺便说一句，Eclipse Maven插件支持这种方法以及更常见的单模块每项目方法。

来源

2009-12-14 09:34:03

这实际上是我想避免的，我可以看到，当我尝试使用嵌套模块时（如'数据库'具有mysql和postgres子目录），变得非常难看“。 – Bill 2009-12-14 09:59:09

@Bill，使用Maven2设置，情况并非如此......该项目将引用“mysql”和“postgres”，但不包含这些组件的源代码的副本;相反，构建会导致JAR库依赖项被下载和链接。 – 2009-12-14 17:10:56

@票据 - 美观（或在这种情况下丑陋）是在旁观者的眼中。真正重要的是你/你的同事能否找到文件。 – 2009-12-14 21:28:22

你要做什么会给你带来很多长期的麻烦......每个独立的组件都应该被真正的制作到自己的项目中，否则你可能会遇到很多问题一个组件发生更改会破坏其他组件并更新时间过长。我强烈建议你将每个组件放到它自己的项目中，并使用Maven2来构建。

来源

2009-12-14 17:09:26

我想你在这里实际上有三个问题。

如何布局您的项目，以使工件有意义。
如何最好地处理每个项目的这些工件的共享。
如何在将开发团队转换为使用新项目结构的同时处理生产力损失。

对于第一个问题，尽量使用Maven约定，并将项目组织到多个工件中。如果工件应嵌套在父项下，请这样做。从最简单的没有依赖关系的工件开始，通过代码工作。

我不确定为什么你认为布局不支持传统的Java层次结构？它应该工作，特别是如果你使用家长团体。

很明显，第二个问题可能会变得很少，这取决于你如何处理第一个问题。我会在创建更多的工件而不是更少的方面犯错，并使用像Nexus或Artifactory这样的资源库管理器来管理它们。至少这样，你的团队的构建可以依靠预先构建和测试的jar来打开你的存储库，以便下载他们正在使用的jar的最新SNAPSHOT或RELEASE。

第三，确保您使用的是具有Maven支持的IDE。如果您坚持使用Rational Application Developer 7.0.x或基于Eclipse 3.4以外的IDE，那么您将无法使用M2Eclipse插件。如果没有M2Eclipse，开发者将不得不跳过一些不理想的手动箍。 Netbeans 6.7和6.8有很好的Maven支持。

来源

2009-12-14 19:07:59

maven-eclipse-plugin工作得很好，如果你不能使用m2eclipse，它是一个相当不错的选择。 – 2009-12-16 19:11:58

你可以用Buildr来做到这一点。你可以活一段时间。

当然，像大多数人一样，我不推荐这种方法。您也可以使用base_dir更改项目的基础目录。

来源

2010-08-01 11:58:21

构建系统，允许在不同的二进制文件之间共享模块

回答

相关问题