所有 Java 构建工具都是怎么回事？
使用 ant、maven 和 buildr 有何意义？在 eclipse 或 netbeans 中使用 build 不能正常工作吗？我只是好奇扩展构建工具的目的和好处是什么。
what's the point of using ant, maven, and buildr? won't the using build in eclipse or netbeans work fine? i'm just curious what the purpose and benefit of extended build tools are.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
依赖关系管理：构建工具遵循组件模型，该模型提供有关在何处查找依赖关系的提示。在 Eclipse/Netbeans 中，您必须依赖一个 JAR，并且您并不真正知道这个 JAR 是否已更新。使用这些构建工具，它们“知道”依赖项的更新（通常是因为与源代码控制存储库的良好集成），重新计算传递依赖项并确保所有内容始终使用最新版本构建。
访问控制：Java除了类级访问控制外，没有更高的抽象。使用这些构建工具，您可以准确指定您想要依赖的项目，并以更高的粒度控制可见性和访问权限。
自定义控件：Eclipse / Netbeans 构建始终构建 JAR 文件。通过自定义构建机制，如果您愿意，您可以使用额外的元数据信息构建自己的自定义（公司内部）存档。
插件：构建工具附带了各种插件，可以在构建过程中执行各种操作。从生成 Javadoc 之类的基本内容到运行测试和获取代码覆盖率、静态分析、生成报告等更重要的内容。
传输：一些构建系统还管理档案的传输 -从开发系统到部署或生产系统。因此，您可以配置传输路线、时间表等。
查看一些持续集成服务器，例如 CruiseControl 或 Hudson。此外，Maven 的功能页面 提供了一些您想了解的信息。
Dependency Management: The build tools follow a component model that provides hints on where to look for dependencies. In Eclipse / Netbeans, you have to depend on a JAR and you don't really know if this JAR has been updated or not. With these build tools, they 'know' updates in dependencies (generally because of a good integration with your source control repository), recalculate transitive dependencies and ensure that everything is always built with the latest versions.
Access Control: Java, apart from class level access control, has no higher abstraction. With these build tools you can specify exactly which projects you want to depend on you and control visibility and access at a higher level of granularity.
Custom Control: The Eclipse / Netbeans build always builds JAR files. With custom build mechanisms, you could build your own custom (company-internal) archive with extra metadata information, if you so wish.
Plugins: There are a variety of plugins that come with build tools which can do various things during build. From something basic like generating Javadocs to something more non-trivial like running tests and getting code coverage, static analysis, generation of reports, etc.
Transport: Some build systems also manage transport of archives - from a development system to a deployment or production system. So, you can configure transport routes, schedules and such.
Take a look at some continuous integration servers like CruiseControl or Hudson. Also, the features page of Maven provides some insight into what you want to know.
在所有其他答案之上。我保持项目可构建而不被迫使用 NetBeans 或 Eclipse 的主要原因是它使设置自动化（和连续）构建变得更加容易。
设置一个以某种方式启动 eclipse、从存储库更新源、构建全部、发送包含结果的邮件并将输出复制到磁盘上最后 50 个构建的某个位置的服务器会相当复杂（相比之下）被存储。
On top of all the other answers. The primary reason I keep my projects buildable without being forced to use NetBeans or Eclipse is that it makes it so much easier to setup automated (and continuous) builds.
It would be rather complicated (in comparison) to set up a server that somehow starts eclipse, updates the source from the repository, build it all, sends a mail with the result and copies the output to somewhere on a disk where the last 50 builds are stored.
如果您是单个开发人员或非常小的团队，那么构建系统似乎只是一种开销。随着开发人员数量的增加，跟踪所有更改并确保开发人员保持同步很快就会变得困难。随着团队的成长，构建系统可以降低这些开销的增长率。一旦您有超过 100 名开发人员参与该项目，请考虑在 Eclipse 中构建所有代码的问题。
拥有单独的构建系统的一个令人信服的原因是确保交付给客户的内容是根据签入 SCM 的代码的特定版本进行编译的。这消除了一整类“在我的盒子上工作”的问题，在我看来，这种好处本身就值得在减少支持时间方面付出努力。孤立的构建（例如在 CI 服务器上）也突出了问题在开发过程中，例如，已经提交了部分或重大更改，因此您有机会尽早发现问题。
IDE 中的构建会构建盒子上出现的任何内容，而独立构建系统将直接从 SCM 生成可重现的构建。当然，这可以在 IDE 中完成，但据我所知，只能通过调用 Ant 或 Maven 之类的东西来处理所有构建步骤。
当然，构建系统还有直接好处。模块化构建系统减少了复制粘贴问题并处理依赖关系解析和其他构建相关问题。这应该让开发人员能够专注于交付代码。当然，每个新工具都会引入自己的问题，并且所涉及的学习曲线可能会使构建系统看起来是不必要的开销（仅 Google 我讨厌 Maven 来了解一些想法）。
If you are a single developer or a very small group, it can seem that a build system is just an overhead. As the number of developers increases though it quickly becomes difficult to track all changes and ensure developers are keeping in sync. A build system reduces the rate of increase of those overheads as your team grows. Consider the issues of building all the code in Eclipse once you have 100+ developers working on the project.
One compelling reason to have a separate build system is to ensure that what has been delivered to your customers is compiled from a specific version of the code checked into your SCM. This eliminates a whole class of "works on my box" issues and in my opinion this benefit is worth the effort on its own in reduced support time. Isolated builds (say on a CI server) also highlight issues in development, e.g. where partial or breaking changes have been committed, so you have a chance to catch issues early.
A build in an IDE builds whatever happens to be on the box, whereas a standalone build system will produce a reproducible build directly from the SCM. Of course this could be done within an IDE, but AFAIK only by invoking something like Ant or Maven to handle all the build steps.
Then of course there are also the direct benefits of build systems. A modular build system reduces copy-paste issues and handles dependency resolution and other build related issues. This should allow developers to focus on delivering code. Of course every new tool introduces its own issues and the learning curve involved can make it seem that a build system is a needless overhead (just Google I hate Maven to get some idea).
从 IDE 构建的问题在于，有大量设置会影响构建。当您使用构建工具时，所有设置都会以或多或少可读的形式压缩为一小组脚本或配置文件。在理想情况下，这允许任何人几乎不需要任何手动设置即可执行构建。
如果没有构建工具，甚至可能在一年内编译您的代码几乎是不可能的，因为您必须对所有设置进行逆向工程
The problem with building from the IDE, is that there are tons of settings affecting the build. When you use a build tool all the settings a condensed in a more or less readable form into a small set of scripts or configuration files. This allows in the ideal case anybody to execute a build with hardly any manual setup.
Without the build tool it might become next to impossible to even compile your code in let's say a year, because you'll have to reverse engineer all the settings
不同的特点。例如，Maven 可以扫描您的依赖项并下载它们以及它们的依赖项，因此您无需这样做。即使对于中等规模的项目也可能存在大量的依赖关系。我不认为 Eclipse 能做到这一点。
Different features. For example Maven can scan your dependencies and go download them, and their dependencies so you don't have to. For even a medium sized project there may be a very large number of dependencies. I don't think Eclipse can do that.
@anonymous，
您的团队中的所有人员都在使用 IDE
时间？我可能想构建代码
在无头构建服务器上，是这样的
好的？
使用持续集成
引擎？
也许我还应该卸载 subversion 并使用补丁或仅在 sftp/ftp/Samba 共享上使用 zip 文件夹。
@anonymous,
of your team, is using an IDE all the
time? I might want to build the code
on a headless build server, is that
ok?
using a continuous integration
engine?
Maybe I should also uninstall subversion and use patches or just zip folders on a sftp/ftp/Samba share.
构建工具允许您自动进行构建，无需人工发明，如果您拥有能够构建许多应用程序的代码库（就像我们一样），这是至关重要的。
我们希望确保我们的每个应用程序在任何代码库更改后都可以正确构建。检查这一点的最佳方法是让计算机使用 Continuos 集成工具自动完成此操作。我们只需签入代码，CI 服务器就会发现更改并重建受该更改影响的所有模块。如果有任何损坏，将直接邮寄给负责人。
能够实现自动化是非常方便的。
The build tools allow you to do a build automatically, without human invention, which is essential if you have a code base being able to build many applications (like we do).
We want to be certain that each and everyone of our applications can build correctly after any code base changes. The best way to check that is to let a computer do it automatically using a Continouos integration tool. We just check in code, and the CI server picks up there is a change and rebuilds all modules influenced by that change. If anything breaks the responsible person is mailed directly.
It is extremely handy being able to automate things.
为了扩展 Jens Schauder 的答案，许多构建选项最终都出现在某种 .project 文件中。 Eclipse 的缺点之一是它们在所有项目文件中存储绝对路径名，因此您无法将项目文件从一台计算机复制到另一台计算机，因为另一台计算机的工作区可能位于不同的目录中。
对我来说最重要的原因是自动化构建。
To expand on Jens Schauder's answer, a lot of those build options end up in some sort of .project file. One of the evils of Eclipse is that they store absolute path names in all of it's project files, so you can't copy a project file from one machine to another, which might have its workspace in a different directory.
The strongest reason for me, is automated builds.
IDE 仅在更高的抽象层上工作。
NetBeans 本身使用 Ant 作为其底层构建工具，并且最近可以直接在 NetBeans 中打开 Maven 项目。因此，您的典型 NetBeans 项目可以使用 ant 进行编译，并且您的 Maven 项目已经是一个 NetBeans 项目。
与每次 GUI 与 CLI 讨论一样，IDE 对于初学者来说似乎更容易，但一旦你掌握了想法，做复杂的事情就会变得很麻烦。
使用 IDE 更改配置意味着单击某处，对于基本操作来说很容易，但对于复杂的操作，您需要找到正确的位置来单击。此外，IDE 似乎隐藏了重要信息。单击按钮添加库很容易，但您可能仍然不知道库在哪里等。
相比之下，使用 CLI 上手并不容易，但很快就会变得容易。它允许更轻松地完成复杂的事情。
使用 Ant 或 Maven 意味着每个人都可以选择自己的 IDE 来编写代码。告诉某人安装 IDE X 来编译它比告诉“在 shell 中运行”要消耗更多的开销。当然，您无法向外部工具解释前者。
综上所述，IDE本身使用了一个构建工具。如果使用 NetBeans Ant（或 Maven），那么您可以获得它们的所有优点和缺点。 Eclipse 使用它自己的东西（据我所知），但也可以集成 ant 脚本。
至于构建工具本身，Maven 与 Ant 有很大不同。它可以下载指定的依赖项，直至下载 Web 服务器来运行您的项目。
IDEs just work on a higher abstraction layer.
NetBeans nativly uses Ant as its underlying build tool and recently can directly open maven projects in NetBeans. Hence, your typical NetBeans project can be compiled with ant and your maven project already is a NetBeans project.
As with every GUI vs CLI discussion, IDEs seem easier for beginners but once you get the idea it becomes cumbersome to do complex things.
Changing the configuration with an IDE means clicking somewhere which is easy for basic things but for complex stuff you need to find the right place to click. Furthermore IDEs seem to hide the importent information. Clicking a button to add a library is easy but you may still not know where the library is, etc.
In contrast, using a CLI isn't easy to start with but becomes quickly easy. It allows to do complex things more easily.
Using Ant or Maven means that every one can choose his/her own IDE to work one the code. Telling someone to install IDE X to compile it is much more overhead than telling "run <build command> in your shell". And of course your can't explain the former to an external tool.
To sum up, the IDE uses a build tool itself. In case of NetBeans Ant (or Maven) is used so you can get all the advantages and disadvantages of those. Eclipse uses its own thing (as far as I know) but also can integrate ant scripts.
As for the build tools themselves Maven is significantly different from Ant. It can download specified dependencies up to the point of downloading a web server to run your project.
在所有项目中，开发人员经常会手动调用构建过程。但这并不适合大型项目，因为在大型项目中很难跟踪需要构建的内容、构建的顺序以及构建过程中存在哪些依赖关系。因此，我们为我们的项目使用构建工具。
构建工具在应用程序中完成开发人员在日常生活中要做的各种任务。
他们是
1.下载依赖项。
2.将源代码编译为二进制代码。
3.打包二进制代码。
4.运行测试。
5.部署到生产系统。
In all projects, developers will often manually invoke the Build process.but it is not Suitable for large Projects, Where it is very difficult to keep track of what needs to be built, in what sequence and what dependencies there are in the building process.Hence we Use Build Tools for Our Projects.
Build Tools Done varieties of the task in the Application which will do by the Developer in their daily life.
They are
1.Downloading dependencies.
2.Compiling source code into binary code.
3.Packaging that binary code.
4.Running tests.
5.Deployment to production systems.