Maven令我震惊的是，这是由一群过去的按日期出售的c-shell脚本小子写的，他们认为autoconf是领先的边缘代码自动化，并且不了解目标代码需要存在目标环境任何有效的开发或部署方式。Ant够糟糕的了，但是Maven结合了Ant和Ivy的所有最差的功能。它不会创建对象环境，并且不能与具有此功能的工具完美配合。
简而言之，一个对象环境应该具有所有类对象，即确定系统可用，始终可用和可用的对象类型的对象。从那里，我可以做任何我想做的事情，实例化一个类的多个对象，设置各种序列和实例化规则，等等。由于环境应该是完全活动的，所以我不需要一个构建工具。就部署我的应用程序而言，环境简单地抛出组成应用程序的名称空间中从未被代码引用的所有类对象并不困难。如今，JVM中的垃圾收集器几乎可以即时执行相同的操作。那时，我有一个部署环境，该部署环境由我的对象和我的对象引用的所有对象（主要是类对象）组成，即我的应用程序和所有依赖项。这就是虚拟机的工作方式。（以至于我们的VM编写得很差，我们需要在Java VM上的Java VM上的Spring VM上运行，而在另一Linux VM的VMWare VM上运行Spring VM则是软件开发的另一个典型例子）。更新依赖项后，环境很容易提示开发人员将其旧代码合并到新库中，使用新的库将代码合并到较低版本，或同时保留两个版本。提示鼓励开发人员进行一些微小的修改，这些修改有时是避免每个库具有二十个版本所必需的，而Maven之类的工具掩盖了您拥有二十个版本这一事实，并导致Java应用程序普遍出现大量运行时膨胀。
在Java开发空间中，Eclipse最接近成为一个合适的对象环境，尽管可以使用许多插件以各种方式打破这种范式。严格审查后，给出使用Maven的大多数原因都无法解决。
Netbeans和Idea是过分的文本编辑器，而不是对象环境，但是，如果您确实想将其工具用于数千个Eclipse插件无法涵盖的东西，它们都可以导入和维护Eclipse项目，那么与开发人员相比，您的构建速度会非常慢使用Eclipse，但是如果它们只是纯Netbeans或Idea项目，它们的速度就会变慢。
不是使用Maven的重要理由。
在Eclipse中轻松导出/导入设置（任何情况下每个团队都应在任何IDE中执行的操作）使得不同的设置问题无非是开发团队的懒惰（或关于空格与制表符的宗教争论，哈哈） 。
同样，不是使用Maven的重要理由。
团队环境？向我展示一个尚未使用GIT或SVN之类的存储库的团队。为什么还要通过设置Nexus存储库来复制功能和维护上的麻烦呢？
那实际上是不使用Maven的充分理由。
运行服务器版本？好主意，现在不应该从实际签入源存储库的代码开始，而不是由偶然推送到Nexus的随机构建开始吗？这就提出了反对Git的观点，尤其是Maven的Git。由于在Git中，我不在分支上工作，所以在本地测试然后提交（部分原因是由于Jenkins和Eclipse中Maven配置的差异，本地测试无法证明服务器的构建工作正常），因此我必须将更改提交到为了查看服务器Maven构建失败，然后执行另一个更改以解决该问题，从而导致回购中的源历史记录不可读，请查看其他分支。检入的代码至少应建立并通过单元测试，如果Git和Maven不在图片范围之内，则应该保证这些代码可以通过。
如果您真正研究一下，从Eclipse导出无头构建很简单-您需要的只是ant或Gradle，由Eclipse维护的开发人员构建，以及一些Eclipse jar（Eclipse将无头构建的所有必要文件导出到Eclipse中。目录或zip文件，或通过ftp将其发送到构建服务器）。诸如Hudson / Jenkins之类的服务器构建工具可以从大多数源存储库中提取更新的代码并调用任何构建脚本，而对Maven则没有依赖性。借助Maven，您要么迫使开发人员使用一种不适合任何人，而是由构建工程师使用的工具（这种构建所花费的时间更长，甚至使用M2E也足以满足这种情况），或者您可能会构建服务器不工作很喜欢工作站版本，这是尚如果您经历了使用大量M2E插件将两者集成的所有麻烦，则为true。无论哪种方式，您都将获得同样慢且更脆弱的服务器版本，从而获得更慢且更脆弱的工作站版本。在我从事的每个基于Maven的项目中，我都看到过临时性的Hudson / Jenkins错误不会在Eclipse中显示，除非您安装并正确配置了所有可能的M2E插件，而大多数开发人员却从未这样做。
似乎是避免使用Maven的另一个重要原因。
这并不涉及Maven的一些更基本的问题，例如其名称空间破坏了Java名称空间和XML名称空间，它是构建单元（POM）与实际部署环境中的任何内容都不相关（请考虑一下，当您分离时通过POM，您在最终产品中实际完成的工作是什么，它所完成的只是一种错误的感觉，即您已将关注点和功能分离到了可以运行的不同构建单元中作为一块完整的代码）；手动维护复杂的配置文件的麻烦，只有在您碰巧需要使用OSGi或另一个容器并且不得不维护影响Maven配置并受其影响的其他配置文件时，这种情况才会变得更糟；试图在没有完整的代码执行环境的情况下运行单元测试而导致的问题；不仅有依赖项的无数版本，而且包括Maven特定插件的版本（我实际上已经在Maven构建本身中看到JAR地狱，其中多个Maven插件使用冲突的依赖项-Maven应该解决的问题之一。
是的，您可以使用Maven构建目标代码。您也可以用C甚至汇编器编写纯目标代码，但是我不知道为什么要这么做。
避免使用Maven的最好原因是，当您厌倦了上面提到的所有问题（以及许多未提及的其他问题）时，取消一组项目的大量工作需要大量的工作。
从C开发继承而来的想法是，开发周期包括编写代码，编译，汇编，构建，部署，测试，再做一次，在对象环境中已经过时了。在某个时候，我们需要告诉所有有这种观念的人，他们需要重新学习如何发展。这样做将消除对Maven，Git和许多其他工具的需求，这些工具只会浪费时间。
对象开发应该在活动对象环境中进行，因为修改后的对象是活动的，因此在代码更改保存时对其进行测试。部署应该包括从该环境中删除仅开发工件，创建一个运行时，该运行时具有正在运行的应用在开发和测试中使用的所有内容。
我目前正在解决由使用maven-assembly插件为OSGi应用程序创建部署程序集引起的问题。该应用程序在Eclipse环境中完美运行，该环境将所有代码更改热部署到环境中正在运行的OSGi容器中。但是，尽管有一位非常出色的配置/构建工程师，唯一的工作就是完成该过程，但该配置无法在Maven组装过程中保持原样。如果我们摆脱了Maven（由于代码量很大，现在很困难，但是有可能）并使用了BNDTOOLS Eclipse插件，我们可以简单地将Eclipse构建导出为Ant或Gradle无头构建（请注意，编写BND的OSGi开发人员和BNDTOOLS不要支持Maven，并且有充分的理由，Maven插件由自己使用Netbeans和Maven的Felix开发人员编写，除了部署周期结束时没有其他活动环境），这两个工具都设置了与Eclipse相同的环境，没有GUI对象，这些对象仅适用于开发人员。结果将是相同的配置并为部署而构建。这样，每个开发人员当前每天花在观看缓慢的Maven或M2E构建上的费用就可以轻松节省2-3个小时，并使配置/构建工程师腾出时间来对部署主机上的应用程序进行更多测试。
克服写/编译/汇编/构建/部署/测试的思维方式是唯一的主要障碍。假装您是在1979年VT100终端而不是现代机器上进行编码，并不能使您成为“真正的”开发人员，它仅表明您的方法已过期35年。
在团队中的开发人员中，没有其他人充分理解像Eclipse这样的活动对象环境，以使其能够与M2E和OSGi一起作为活动环境使用，他们是顶尖的开发人员，由于没有接触过它，因此到过时的命令行开发工具的普及。他们只知道，原来是可以这样做的时候，我们是结对编程解决配置问题和我分享我的画面，引起了其他团队成员之一惊呼“这是 您如何快速地编写代码”，当他看到我的代码更改立即在后台OSGi容器中进行测试时，我可以在必要时使用bash shell，例如，当我查看远程服务器上的日志时，事实上，我的工作方式相当准确，因此我可以尽快摆脱那种环境，回到21世纪。