对于为基于tools.build的构建使用“标准”构建任务名称的想法，有何思考？
这可能是在tools.build（的底层）中实际编写代码的形式，或者仅仅是一个官方发布的约定。在这个阶段，我更感兴趣的是这个一般概念是否在视野之中，如果是的话，它可能是什么样子，而更少关注实施的具体细节。
这很重要，因为在赋予作者命名他们构建任务的权利的同时，虽然对作者来说有一些（较小的）价值，但它却导致构建的最后用户体验变得零散——一个消费者不能对其遇到的每个基于tools.build的新项目进行任何假设，以便他们自己构建。
虽然人类可以通过反省构建脚本来了解如何操作它，但对于基于构建的下游自动化来说，这要困难得多；包括（但不仅限于）jitpack.io，Heroku等系统。
在刚开始尝试tools.build之后，现在的版本感觉非常像2004年左右的Java构建环境（在Maven 1.0发布之前）。当时Apache Ant是主要的构建工具，每个Ant构建脚本都是一个独一无二的“小雪花”，迫使消费者在使用之前花费时间去研究。虽然Apache Ant有许多实质性缺陷，但Maven 1.0至少解决了这个问题。虽然将tools.build与Apache Ant进行比较在许多方面都是明显的羞辱（tools.build的脚本语言、可组合性和依赖管理部分显然远超Ant），但缺乏一个良好的“接口”进入基于tools.build的构建脚本让我有强烈的 deja vu...
