2024年Clojure状态调查!分享您的想法。

欢迎!有关此如何运作的更多信息,请参阅关于页面。

+2
工具
编辑

对于在基于tools.build的构建中实现“标准”构建任务名的主意,有没有考虑过什么?

这可能是在tools.build(或其上的一层)的实际代码中,或者是简单的官方、公开的约定。在这个阶段,我更感兴趣的是这个概念是否在考虑之中,以及如果考虑,它可能看起来是什么样子,而不是特别关心具体实施细节。

这很重要,因为虽然允许作者按他们的意愿命名他们的构建任务对那些作者来说有一些(小?)价值,但它会导致构建消费者的体验变得支离破碎——消费者无法对每个遇到的新基于tools.build的项目假设他们能自己构建。

虽然人类可以内省构建脚本以了解如何操作它,但对于下游基于构建的自动化来说,这要难得多;包括(但不仅限于)jitpack.io,Heroku等系统。

在我开始尝试使用tools.build之后,当前版本让我感到非常像2004年左右(Maven 1.0发布之前)的Java构建环境。当时Apache Ant是主导的构建工具,每个Ant构建脚本都是独一无二的,迫使消费者在有效使用它之前花费时间学习。尽管Apache Ant存在大量重大缺陷,但Maven 1.0至少解决了这个问题。虽然在许多方面(包括但不限于scripting语言、组合性和依赖关系管理组件)将tools.build与Apache Ant相比较显然是一种巨大的不公正(tools.build的脚本语言、组合性和依赖关系管理部件明显领先于Apache Ant),但缺少对基于tools.build的构建脚本的明确“接口”给了我一种强烈的似曾相识的感觉...

1 答案

0

我认为目前还没有什么“官方的”。但是,如果你还没有看过,你可以看看Sean Corfield的 build-clj


编辑
是的,我在使用build-clj。事实上,它促成了这一思考过程。

[编辑] 另外为了增加一些细微差别,虽然build-clj为常规构建任务提供了标准 _实现_,但它没有提及这些构建任务的标准 _接口_(后者是本问题的重点)
...