我使用 Java/Eclipse 进行开发,但我从未真正使用过任何传统的构建工具,如 ant 或 maven。我一般只依赖通过eclipse构建项目,很少使用命令行。我真的不想花时间去了解 ant/maven,但我想知道 eclipse 是否真的可以通过其 .classpath 文件任何其他设置来替代 ant/maven 的所有功能。
(请不要向我推荐一些使学习 ant 变得非常容易的教程)。
Eclipse 知道如何基于.project
和.classpath
文件构建项目。
build.xml
是 Ant 使用的构建规则的默认文件名,这样当你ant
不带参数运行时,它会使用这个文件来确定要做什么。
pom.xml
是描述 Maven 项目的默认文件名,因此当您运行时mvn compile
,它将使用此文件来确定如何构建项目。
Eclipse 可以基于 Ant 构建文件或 POM 文件导入项目,并创建相应的.project
文件.classpath
。
Eclipse、Ant、Maven 都是不同的工具,不能互相替代。它们有一些重叠的功能,但也有一些独特的功能。
能够使用命令行构建项目是一项非常有用的技能,也是成为一名优秀程序员的一部分。在程序员能力矩阵中,能够使用命令行构建软件被认为是 1 级(在 0、1、2、3 级之外),如果你不能做到这一点,那就不是很好。 http://www.indiangeek.net/programmer-competency-matrix/
我强烈建议学习 Maven。
如果您的应用程序在 Eclipse 之外几乎没有存在,那么也许您应该继续以这种方式使用 Eclipse。但是 Eclipse 是一个开发人员工具(开发人员就像编写代码的人一样)。除了最琐碎的项目之外,任何其他项目都必须处理开发人员以外的角色。应用程序会经历一个完整的生命周期。事实上,存在着不同的生命周期轴,无论是从项目管理的角度来看,还是从可交付成果的角度来看,例如编码、编译、组装依赖关系、打包、部署等多个阶段,或者从其他角度来看。
当您查看那些经过各个阶段的可交付成果时,可以在 Eclipse 中(手动)完成其中的许多步骤。所以,再一次,如果这对你有用,赞美。但是,它错过了自动化,并且对于某些步骤(阶段)来说,Eclipse 并不是正确的工具。例如:持续集成不是为 Eclipse 构建的。CI 服务器可能想要检查您的源代码并从头开始构建东西。它需要查找依赖项等,可以根据 Eclipse 的.classpath
文件进行查找,但这会引入对 Eclipse 的依赖项。现在,我已经看到大公司正是这样做的,但它有点笨拙,因为这又不是 Eclipse 的本意。
相反,有一些工具可以很好地处理整个*生命周期。
*请注意,“整个”是一个非常主观的问题。从开发人员的角度来看,生命周期可以很好地分成几个阶段,但是您较大组织中的其他人可能会发现他们的职责在任何给定的生命周期阶段细分中都没有得到充分代表。
Maven 或 Gradle 就是这样的工具。将它们视为具有多个工作站的装配线。开发人员在其中一个工作站使用 Eclipse,但在装配线下方不断滚动。CI 是另一个工作站,使用 Bamboo、Hudson、Jenkins 或类似工具,但仍在工作的装配线下方。在 Eclipse 中,m2e 插件是 Eclipse 和装配线 Maven 之间的连接器。
解决此问题的另一种方法是使用脚本,或者替换您在 Eclipse 中执行的手动步骤,将它们连接在一起,或者补充它们。显然有许多语言可以使用,但在构建工具领域内,Ant 非常流行,因为它的功能与此目的完全一致。
如果您是一家专业的软件工厂(可能已经是单个开发人员项目的情况),您需要一条装配线。Maven 或 Gradle 给你一个开箱即用的。如果你想逆流而上,你可以自己构建,使用 Ant 或其他东西。如果您在这方面确实没有要求可言,请继续在 Eclipse 中手动操作。
尽管 Ant 是用 XML 定义的,但作为开发人员,Ant 对我们来说很自然,因为它有很多传统的顺序编程语言。Maven 和 Gradle 有不同的方法,因此学习曲线更陡峭。但这绝对值得。如果您按照他们的方式进行操作,事情就会变得轻而易举,您不必编写所有其他想要添加到装配线的东西。这种手工制作的脚本总是从很小的地方开始,但它们永远不会保持这种状态,是吗?:)
除此之外,我想提一下,Maven 也非常擅长解决依赖关系。这就是它最出名的地方,但这不是这个问题的目的,事实上它只是它能为你做的一小部分。