构建允许在不同二进制文件之间共享模块的系统
我试图选择最合适的构建系统来在具有公共源代码存储库的企业中工作，强调公共代码的共享。我希望源层次结构看起来像这样：
- src
- java
- common
- net
- database
- team1
- team2
- team3
- lib
- tests
- java
- common
- net
- database
- team1
- team2
- team3
- lib
目标是拥有一个构建系统，其中 team[1-3] 可以拥有显式指定其依赖项的独立构建。依赖关系可能如下所示：
- team1 - common/net - team3/lib - team2 - common/database - team3
因此，例如，team1 的构建将包括 team1、common/net 和 team3/lib 中的所有内容；但没有别的。理想情况下，测试将以相同的方式集成（测试 team1 将为 team1、common/net 和 team3/lib 运行测试）。
我目前正在使用 Ant，但还没有找到一种合理的方法来管理这样的层次结构。我开始关注 Maven 2 的管理依赖层次结构的能力，但它似乎希望每个模块都有成熟的项目。这不会是一个问题，但它似乎迫使我进入一个不能很好地映射到传统 java 包层次结构的目录结构。看来我可以使用 替代布局 来使用 buildr 做我想做的事情，但我担心这可能会变得脆弱。
有人可以推荐一些可能对我有用的东西吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为你这里实际上存在三个问题。
对于第一个问题，尽可能使用 Maven 约定并将项目组织为多个工件。如果工件应嵌套在父项下，请这样做。从没有依赖关系的最简单的工件开始，然后按照您的方式完成代码。
我不确定为什么您认为布局不支持传统的 Java 层次结构？它应该可以工作，特别是如果您使用父 pom。
显然，第二个问题可能会变得相当棘手，具体取决于您如何处理第一个问题。我会错误地创建更多的工件，而不是更少的工件，并使用像 Nexus 或 Artifactory 这样的存储库管理器来管理它们。至少这样，您的团队的构建可以依靠预先构建和测试的 jar，通过访问您的存储库来获取他们正在使用的 jar 的最新快照或版本。
对于第三点，请确保您使用的 IDE 支持 Maven。如果您一直使用 Rational Application Developer 7.0.x 或基于 Eclipse 3.4 以下版本的 IDE，那么您将无法使用 M2Eclipse 插件。如果没有 M2Eclipse，开发人员将不得不跳过一些不理想的手动操作。 Netbeans 6.7 和 6.8 具有非常好的 Maven 支持。
I think you actually have three issues here.
For the first issue, try to use Maven conventions wherever possible and organize the project into multiple artifacts. If the artifacts should be nested under a parent, do so. Start off with the simplest artifact which has no dependencies and work your way through the code.
I'm not sure why you believe the layout won't support the traditional Java hierarchy? It should work, especially if you use parent poms.
Obviously the second issue can become quite a handful depending upon how you handle the first one. I would err on the side of creating more artifacts instead of fewer and using a repository manager like Nexus or Artifactory to manage them. At least that way, your team's builds can rely on pre-built and tested jars by hitting your repository to pull down the latest SNAPSHOT or RELEASE of the jar they are working with.
For the third, make sure you're using IDEs that have Maven support. If you're stuck using something like Rational Application Developer 7.0.x or an IDE based on something less than Eclipse 3.4, then you won't be able to use the M2Eclipse plugin. Without M2Eclipse, the developers will have to jump through some manual hoops which are not ideal. Netbeans 6.7 and 6.8 have very good Maven support.
正如您所说，Maven 2 是您的情况的首选。
Maven 文件夹结构并不疯狂——它是可配置的，如果你认为它不合适的话。然而，我认为这是一个很好的结构，你可以毫无悔意地遵循。
您可以使用存储库管理器，这样使用某些依赖项的人不一定需要签出他们的项目依赖。
As you say, Maven 2 is the preferred option for your case.
Maven folder structure is not madnatory - it is configurable, if you consider it unsiutable. However, I think it is a good structure that you can follow without remorse.
You can use a repository manager so that people who use some dependencies don't necessarily need to checkout the projects they depend on.
这是一种方法。或者，多模块 Maven 项目可以这样组织：
其中每个 pom.xml 也可以引用其他树定义的模块。顺便说一句，Eclipse maven 插件支持这种方法以及更常见的每个项目一个模块的方法。
That's one way to do it. Alternatively, a multi-module Maven project can be organized like this:
where each pom.xml could also refer to modules defined by other trees. BTW, the Eclipse maven plugin supports this approach as well as the more common one-module-per-project approach.
这是令人惊讶的，因为 Ant（+Ivy？）为您提供了您想要的所有灵活性。
如果您的意思是每个模块一个
pom.xml，那么这是正确的。是的，Maven 有一些约定，项目目录结构就是其中之一。虽然这是（有点）可配置的，但我认为您无法匹配所需的布局（将测试和源放入单独的层次结构中）。实际上，如果你选择 Maven，我强烈建议使用默认值，你应该采用它的理念，它会为你省去很多，真的很多，痛苦（更不用说有些插件可能会以硬编码方式使用这些默认值）。
老实说，我不太明白你所说的目录结构不能很好地映射到传统的java包层次结构是什么意思。首先，Maven 对于 Java 来说是完美的，所以这对我来说没有任何意义。其次，这可能更主观，您的布局（具有单独的测试和源树）对我来说看起来根本不传统。也许你应该澄清传统的确切含义......
我不太了解构建器，所以我不能说太多，但我知道它确实更加灵活。也就是说，如果 Ant 在灵活性方面不能让您满意，那么我不明白为什么 buildr 会更好。
并且不要忘记，与 Maven 相比，buildr 和 Ant+Ivy 的社区要小得多。不要低估这一点，这可能会成为一个真正的问题。
就我个人而言，我会选择 Maven 并重新考虑你的布局。但假设我有偏见。
This is surprising as Ant (+Ivy?) gives you all the flexibility you want.
If by this you mean one
pom.xmlper module, then that's correct.Yes, Maven comes with some conventions, the project directory structure being one of them. This is (a bit) configurable though but I don't think you'll be able to match the wanted layout (with tests and sources into separated hierarchies). And actually, I would strongly advice to use defaults if you go for Maven, you should adopt its philosophy, it will save you a lot, really a lot, of pain (not even mentioning that some plugins might use these default in an hard coded way).
To be honest, I don't really understand what you mean by a directory structure that does not map well to the traditional java package hierarchy. First, Maven is perfect for Java, so this doesn't make any sense to me. Second, and this might be more subjective, your layout (with separated tests and sources trees) doesn't look traditional at all to me. Maybe you should clarify what you mean exactly by traditional...
I don't know buildr really well so I can't say much about it but I know it is indeed more flexible. That said, if Ant doesn't give you satisfaction in terms of flexibility, then I don't see why buildr would be better.
And don't forget that buildr and Ant+Ivy have much smaller communities compared to Maven. Don't underestimate this, this might become a real concern.
Personally, I would go for Maven and reconsider your layout. But let's say I'm biased.
从长远来看，您所追求的将会给您带来很多麻烦...每个独立组件都应该真正制作成具有自己存储库的自己的项目，否则，您可能会因其中一个组件的更改而遇到很多问题组件破坏了其他组件并且更新时间过长。我强烈建议您将每个组件制作成自己的项目并使用 Maven2 进行构建。
What you are going for is going to give you lots of trouble in the long-term... each standalone component should really be made into its own project with its own repository, otherwise, you can get into lots of issues with changes in one component breaking the other components and updating taking excessively long. I strongly recommend that you make each component into its own project and using Maven2 to build.
您可以使用 Buildr 来完成。你可以和它一起生活一段时间。
当然，像线程中的大多数人一样，我宁愿不推荐这种方法。
您还可以使用 base_dir 更改项目的基目录。
You can do it with Buildr. You could live for some time with it.
Of course, like most people on the thread, I would rather not recommend this approach.
You can also use base_dir to change the base directory of the projects.