“我们对Maven 4甚至Maven 5都有想法”-采访Maven项目的主要参与者Robert Scholte

承认,我们所有人在漫长的夜晚和夜晚都在Maven进行建筑设计,那时我真的很想告诉这个技术丰富的创作者。 有时候梦想成真! Zhenya和我( phillennium )遇到几乎最主要的Maven开发人员-Robert Scholte。 我们问他的是什么...



阅读更多→


在新的发行周期中,Java版本陆续出现,第11个版本已经出现,而许多版本则排在第8个。 您将很快发表有关Maven如何支持所有这些内容的演示 ,并且您不想破坏报告,而是向这个方向提问。 您个人认为这个新的发布周期会给您增加工作量吗? 这是好还是坏的变化?


如果您谈论的是6个月的发布周期,那么对于Maven来说,这会有点快。 我们的团队很小,我们大约有5-10名积极参与者,他们都是志愿者,没有公司在开发Maven。 因此,每个人都应该在空闲时间从事该项目。 Java的更改需要大量工作。 每次发布新版本时,我们都需要提供其支持,这意味着我们没有时间使用Maven,其插件或其他任何工具。 如果周期为一年半半,那对我来说会更好。




其他为Java生态系统开发项目的人是否也有类似的感觉,是否还需要为最新版本提供支持?



通过twitter判断,那么是的,大多数人都认为6个月太快了。




你能说说Maven的故事吗? 如果我没记错的话,它是很久以前创建的,目的是使Apache Turbine的构建不那么恐怖和痛苦。 顺便说一句,我使用了Apache Turbine。 你还记得这次吗?


Maven的故事很久以前就开始了。 我大约在8年前加入了该项目,也就是在3.0.3或3.0.4版本期间。 至此,Maven已经存在了一段时间。 据我所知,他是Turbine项目的一部分。 这个项目的一部分制作了一个单独的工具,即Maven。 那时,我像所有东西一样都使用了Ant。 我不喜欢每次启动新项目时都需要复制所有这些Ant文件。 我知道应该有更好的解决方案,我开始在Internet上搜索它并找到了Maven。 但是,在我了解Maven的主要思想之前,已经花费了很多时间。 但是,当您了解它时,它将变得很方便。 我在Ant身上遇到的所有问题都消失了。 Ant仍然是一个很好的工具,但是如果您正在开发一个包含许多资源的项目,我强烈建议您使用Maven或类似的工具。




Maven与Java有关。 我尝试将其用于C ++,但是效果不是很好。 是否有一段时间不再使用Java,我们将如何做?


在现有的流行的面向对象语言中,Java似乎是最古老的语言之一,它已经有20多年的历史了。 我没有看最新的统计数据,但是我确信Java仍然非常普及。 我认为它将存在相当长的时间。 至少我希望如此-这意味着我不会没有工作。




Maven会活得太久吗?


但这是一个难题。 直到今天,仍有65-80%的Java项目使用Maven。 即使对于已使用15年以上的产品,这也很多。 可能在Maven中可以进行更多改进。 我们对Maven 4甚至Maven 5都有想法,但是实现它们将花费很长时间。 我认为Maven的一般想法不会过时,但是其他组装系统可能会取代它。 因为他们从我们在Maven所做的错误和我们正确做出的决定中汲取经验,并且基于这些经验,所以他们可以从头开始。 Maven的优点之一是向后兼容。 即使使用10或15年前编写的项目,也可以使用最新版本的Maven进行组装。 但是正因为如此,我们在Maven Core中有很多旧代码。 应该将其更换,但这并不是那么容易。



据我所记得,现在您仍然可以构建没有注释的moji。


是的,有可能。




面试之前,我试图找到有关此的教程,但没有发现任何东西。 仿佛语言专家正在追赶我们,并且吞噬了Internet上的所有旧文档。 但是我记得曾经有一段时间没有注释和使用特殊约定。 好吧,让我们继续另一个问题。 您认为Maven有真正的竞争吗? 说摇篮?


Gradle是一个非常强大的竞争对手,已经存在了相当长的时间。 我认为,竞争是件好事,因为它可以使我们保持稳定并让我们看到一些替代解决方案。 他们只是采用不同的方式来收集项目,这没有错。 每个人都应该选择最适合自己项目的东西。 也许我在这里也要提 。 这是ASM团队的Remi Forax编写的工具(字节码解析器)。 他和我一样,是拼图项目专家组的成员。 他想编写一个最能反映Java思想的构建工具。 在创建专业人士时,他借鉴了Maven的最佳方面。 看着这个很有趣。 该演示旨在演示您可以在构建器中使用Java 9模块和相关优点。




您说过您参加了Jigsaw项目-并说了过去时。 他不复存在了? 他还有机会发展吗?


该JSR已关闭。 的确,仍然存在一些未解决的问题,但现在由支持团队处理。




是什么导致了开发Maven的最大困难? 最严重的问题是什么? 不是基于Java 9,而是基于所有开发经验。 您能选择两个最重要的问题吗?


这个问题并不容易,但让我们尝试一下。 发生依赖关系解决的部分非常复杂。 我们仍在努力改善它。 您可能已经注意到,没有Maven 3.4版本,而在3.3.9版本之后立即有3.5.0版本。 这样做的主要原因是在解决依赖关系方面发生了重大变化。 它们被标记为错误修复,但是我们注意到大量项目突然被破坏了-它们依赖于这些奇怪的变化。 这是不可接受的。 因此,我们做了在其他任何情况下都不会做的事情-硬重置的git存储库,在Maven 3.5.0中,我们开始仅选择外部改进。 好吧,当然,我们使控制台变成了彩色-每个人都喜欢它。




好的,现在是第二个难题!


对于我们而言,要找到与Maven社区的联系并教他们如何正确使用该工具并不容易。




因此,每个人都知道如何使用Maven:从Stack Overflow的注释中复制一些XML脚步,然后开始工作。 是不是


好吧好吧 不行 我相信大多数情况下,建议您进行全新安装,这是不正确的。 因此,可能应该在Maven 2中完成。现在,您需要运行mvn verify。 因为当您清理时,所有内容都被删除,整个工作结果。 而且,如果从您那里复制文件-这些是I / O操作,则速度很慢。 通常,很多事情会做很多遍。 大多数插件知道何时需要完成工作。 通常,不需要清洁。 对于安装,此命令仅将您的JAR文件复制到本地存储库。 同样,这是不必要的I / O操作。 此外,您的本地存储库可能会变脏-也就是说,它看起来可能与同事的本地存储库不同。 有时,这可能会导致有趣的结果。 因此,您只需运行mvn verify就足够了。




顺便说一下,我刚刚打开了maven.apache.org ,它说:“ Apache Maven是一个软件项目管理和理解工具”。 但是许多人认为Maven只是另一个构建工具。 组装工具和项目管理工具有什么区别?


最好不要回答这个问题-在网站上写的不是我。 我认为作者想说的是Maven不仅仅是构建一个项目。 他还参与解决依赖性,他提供了一种配置格式,他不允许安装太多东西。 通常,这是世界上所有事物的巨大集合。




Maven团队的主要原则和信念是什么? 例如,他们是否认为声明式方法比命令式方法更好? 类似于Python中的Zen。 您是否有一套类似的规则?


我认为不是。 我们认为,插件的配置应尽可能简单。 如果存在合理的默认值,则应指明它们。 这将使最终用户的生活更加轻松。 多年来,我们最近第一次更改了源版本和目标版本的默认选项-以前是1.5,现在是1.6。 我们希望提供默认选项,因为如果没有默认选项,则会使用JDK中使用的版本。 在这种情况下,如果我使用Java 10,而其他人使用Java 12,我们将得到不同的结果。 您应该始终指定源和目标。 但是,如果您开始使用Java 9,则无法再使用简单的pom文件和一个类创建Hello World,因为Java 9至少需要Java 6作为源值和目标值。 因此,我们决定使用默认版本1.6并添加警告,如果尚未指定版本,则应执行此操作-人们应该知道,如果使用Java 9,则需要设置源版本和目标版本或发行值。或两者兼而有之。




您将来对Maven遇到什么困难? 您说过要尽量不要经常更改Maven。 但是,将来有什么在等待着我们呢?


我们要进行的最重要的更改之一与pom文件有关。 我们发现,在某些部分(尤其是在构建中),最好添加一些其他元素。 但是目前,我们无法做到这一点。 您在系统上使用的同一pom文件已上传。 如果向其中添加其他元素,它们将违反XSD,其他工具将无法使用它。




但是您可以更改标题中的XSD吗?


是的 但是我不认为每个工具都会检查XSD。 他们只是认为他们正在处理版本4.0.0。 因此,进行更改将非常困难。 我们决定将pom文件分为几个部分,并从Build POM开始。 而将要卸载的一个称为“消费者POM”。 它会基于Build POM生成,不需要采取进一步的措施。 并且它将与Maven POM 4.0.0完全兼容。 通过将POM分为两个部分,我们最终可以显着改进它并使Maven易于使用。 这是Maven核心的一个变化,我们已经进行了一年多的研究,包括在IDE中的实现。 这不容易。




出于集成,自动完成,增量编译等原因,某些IDE试图将Maven的一部分包含在IDE中。 怎么做对? 据我所知,Maven的某些部分很早以前就已在Eclipse中构建。


我认为这样的尝试是合理的-由于集成,该系统对用户非常方便。 这归功于Maven 3中实现的重大更改之一。在其中,对该架构进行了重做以在IDE中提供更好的支持。 这些更改的作者与Eclipse紧密合作,并且此解决方案来自此处。 我认为这是允许的。 我知道NetBeans和InelliJ具有完全不同的方法,它们只是从命令行调用Maven而没有任何集成。




另一个重要主题是Maven的速度。 我们可以以某种方式增加它吗? 依赖解析和I / O操作非常慢。 即使在今天,也使用SSD。


是的,可以做些事情。 首先,您需要查看系统中有多少个内核,并使用多个线程启动Maven。 这是解决方案之一。 另外,看看高隆。 这是由Maven的创始人之一Jason van Zayl创建的公司。 他编写了一些有趣的扩展,并大大改善了对并行程序集的支持,即在您构建多个项目时。 我希望有一天他会把这些开发成果交给Maven,但是现在您应该看看他的页面。




您说您在业余时间在Maven上工作,对吗? 您是Maven的创造者之一这一事实是否对您当前的工作有所帮助? 还是只是一种爱好?


我在荷兰的一个政府组织中担任软件架构师。 这就是我谋生的方式。 当然,他们知道我也在Maven上工作,因此他们会定期问我有关Maven的问题。 但总的来说,我只是他们的建筑师。 晚上,我在Maven工作,尝试改进它,帮助人们。




除了Maven以外,您还从事其他开源项目吗?


我参加了另外两个项目。 一个叫做MojoHaus,它为Maven开发了很大一部分插件。 没错,现在我在这个项目中没有做任何事情,但是有时我还是在那里查看并管理各种小事情。 另一个项目称为QDox。 它解析源代码。 它也与Maven相关联,因为它已在某些插件中使用。 这种经验对我有帮助,因为例如在Java 9中引入的模块描述符的情况下,经验允许我在Maven插件中使用描述符。




顺便说一下,您对Java 9、10、11有何看法? 我应该使用它们,还是保留Java 8更好?


迁移到较新的版本。 即使没有使用所有功能,也应该升级到Java 10,或者等待几周再升级到Java11。只需使用类路径即可。 Java由于其模块化而大大提高了速度,但是类路径才可以工作。 我知道许多人仍然认为您需要添加模块描述符或使用模块系统,但这不是必需的。 只需使用classpath。




顺便说一句,您是否熟悉GraalVM项目? 用它来构建Maven怎么样?


上周,我访问了JavaZone,并与Chris和Oleg进行了讨论。 我认为我们需要花一些时间,看看是否有可能通过GraalVM真正提高Maven的性能。 这可能很有趣。




您是Maven的创建者,该项目对Java开发人员非常重要。 您对此有何感想?


我不是该项目的创始人,我参与了该项目的支持。 当他已经走了很长一段路时,我开始与他打交道,似乎我可以接受。 十年前,我本以为我不会进入层次结构的顶端,但是它确实发生了,而且非常酷。 每个人对Maven都有自己的见解,我真的很喜欢当您参加会议时,人们来说他们对Maven感到高兴。 这极大地激励了我,使我有力量在回家后继续从事该项目。



许多开发人员强烈讨厌XML。 我不是其中之一,但是在构建系统时,由于Maven中的pom.xml,总是弹出此主题。 因此,我想知道:您对XML有何看法?


XML的优点是每个人都可以理解它,很容易解析它,并且可以在IDE中提供很好的支持。 我对XML很正常,据我所知,在Maven用户中,仇恨XML的比例不超过5%,但是他们大声地喊着XML! 而您根本听不到其余的95%。 不过,有一个针对这5%的解决方案-在此我想再次提及Takari。 有一个多语言项目,可让您选择其他语法。 因此,如果您想使用Yaml和pom.yml-完全有可能。 您只需要向项目添加扩展名,就可以切换到另一种语言。




还有关于开发人员的心情:我记得Maven邮件列表上的线程 ,SDKMAN工具的作者在哪里! 社区对通过Maven分发Maven的提议做出了回应,例如“我所看到的只是一个愚蠢的名字的项目”和“您可以更好地出售自己的想法”。 然后引发了讨论:有些人认为社区的反应过于激进,而另一些人则认为最初的句子“针对我的工具采取其他措施”是没有根据的。 一种或另一种方式是,许多人对该情况不满意,就此而言,问题是:您认为特别是Maven还是开源社区普遍存在沟通问题?


可以肯定,沟通可能非常非常困难。 尤其是当仅通过文字发生且您看不到对话者在您面前时-在这种情况下,很难解释您想说什么。 我认为每个开源项目都面临着与人正确沟通的问题。 我完全理解为什么项目参与者有时会感到烦恼-他们一遍又一遍地听到相同的问题。 我已经提到过这样一个问题的示例-“为什么不能使用mvn clean install”? 我不再解释这一点,因为否则我会变成一个粗鲁的人,但是我不想要这个。 所以我用其他方式解释了这些事情。 因此,一方面,沟通可能非常困难。 另一方面,尽管Maven不灵活,但这是他成功的一部分。 当人们提出与我们的Maven概念不兼容的报价时,我们只是说:对不起,但这出于某些原因不适合我们。 我完全理解,这可能令人沮丧。 但是总的来说,这种方法只是最好的。




最后,您能否对读者说几句话,建议他们如何走向光明的未来?


正如我所说的,一个小团队正在研究Maven,这是一个每个人都可以参与的开源项目。 没那么难。 我们创建了一个新标签叫抢。 这些问题应该不难解决。 通过这种方式,您可以了解Maven的工作方式。 如果您想加入我们的团队,则以修复示例为例,我们将看到您代码的质量-如果您希望被我们注意,那么我建议您尝试一下。 我真的希望我们的团队在将来成长。




感谢您的回答。 在Joker 2018与我见面!


分钟的广告。 Joker 2018会议将于10月19日至20日举行,Robert将在该会议上发表有关“ Apache Maven支持ALL Java”的演讲。 总的来说,Joker将会有更多有趣且值得注意的报道。 门票可以会议的官方网站上购买。

Source: https://habr.com/ru/post/zh-CN424505/


All Articles