3

I'm trying to choose the most appropriate build system to work in enterprise with a common source repository, emphasizing sharing of common code. I'd like the source hierarchy to look something like this:

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

The goal is to have a build system where team[1-3] can have independent builds that explicitly specify their dependencies. Dependencies might look like:

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

So, for example, the build for team1 would include everything within the team1, common/net, and team3/lib; but nothing else. Ideally, tests would be integrated in the same fashion (testing team1 would run tests for team1, common/net, and team3/lib).

I'm currently using Ant, but haven't found a sane way to manage a hierarchy like this. I started to look at Maven 2 for its ability to manage a dependency hierarchy, but it seems to want full-fledged projects for each module. That wouldn't be a problem, but it seems to force me into a directory structure that does not map well to the traditional java package hierarchy. It seems like I might be able to do what I want with buildr using an alternative layout, but I'm worried that might prove to be brittle.

Can someone recommend something that might work for me?

4

6 回答 6

2

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

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

对于第一个问题，尽可能使用 Maven 约定并将项目组织成多个工件。如果工件应该嵌套在父级下，请这样做。从最简单的没有依赖关系的工件开始，然后按照自己的方式编写代码。

我不确定您为什么认为布局不支持传统的 Java 层次结构？它应该可以工作，特别是如果您使用父 pom。

显然，根据您处理第一个问题的方式，第二个问题可能会变得非常少。我宁愿创建更多的工件而不是更少，并使用像 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-14T19:07:59.393 回答
0

正如您所说，Maven 2 是您案例的首选选项。Maven 文件夹结构不是强制性的 -如果您认为它不合适，它是可配置的。但是，我认为这是一个很好的结构，您可以毫无悔意地遵循。

您可以使用存储库管理器，这样使用某些依赖项的人就不必检查他们所依赖的项目。

于 2009-12-14T07:28:49.930 回答
0

我开始关注 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-14T09:34:03.080 回答
0

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

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

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

如果您的意思是pom.xml每个模块一个，那么这是正确的。

这不是问题，但它似乎迫使我进入一个不能很好地映射到传统 java 包层次结构的目录结构。

是的，Maven 带有一些约定，项目目录结构就是其中之一。虽然这是（有点）可配置的，但我认为您无法匹配所需的布局（将测试和源代码放入单独的层次结构中）。实际上，如果您选择 Maven，我强烈建议您使用默认值，您应该采用它的理念，它会为您节省很多，真的很多，痛苦（甚至没有提到某些插件可能会在硬编码中使用这些默认值方法）。

老实说，我不太明白你所说的不能很好地映射到传统 java 包层次结构的目录结构是什么意思。首先，Maven 非常适合 Java，所以这对我来说没有任何意义。其次，这可能更主观，您的布局（带有分离的测试和源代码树）在我看来一点也不传统。也许您应该澄清传统的确切含义...

似乎我可以使用替代布局对 buildr 做我想做的事，但我担心这可能会变得脆弱

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

并且不要忘记，与 Maven 相比，buildr 和 Ant+Ivy 的社区要小得多。不要低估这一点，这可能会成为一个真正的问题。

就个人而言，我会选择 Maven 并重新考虑您的布局。但是，假设我有偏见。

于 2009-12-14T08:53:22.683 回答
0

从长远来看，您要做的事情会给您带来很多麻烦……每个独立组件都应该真正成为具有自己存储库的自己的项目，否则，您可能会在一个更改中遇到很多问题组件破坏其他组件并更新时间过长。我强烈建议您将每个组件都制作成自己的项目并使用 Maven2 进行构建。

于 2009-12-14T17:09:26.780 回答
0

您可以使用 Buildr 来完成。你可以忍受它一段时间。

当然，像线程上的大多数人一样，我宁愿不推荐这种方法。您还可以使用 base_dir 更改项目的基本目录。

于 2010-08-01T11:58:21.197 回答