summary: Smart Bash Completion, Command Line Task Parameters (completable) instead of magic properties, Command Line Plugins, Even better reporting status: Discussions are happening and we will iteratively add features in this area after 1.0. code: planned
Today’s Gradle already contains very rich information about your project, including the structure of multi-project builds, the purpose of and tasks for each project and so on. Today’s Gradle provides a reasonable command-line interface for interacting with that project knowledege, but we are committed that it go much, much further.
The Gradle command line should, from the first moment of use, guide the user through what is possible in the Gradle build, providing help at every turn, exposing interesting information when appropriate, and hiding needless details at the same time.
For us, the command line is the ultimate proving ground for tool usability. If you get it right at the command line, you have every opportunity to get it right in the GUI or IDE, but the opposite is not necessarily the case. Following in the footsteps of projects like Roo and Git, we are currently in progress making Gradle’s command-line interface world-class.
We think this is important not just because a polished UI looks and feels great, but because the very nature of interacting with a build tool demands this kind of experience. Most users, most of the time, interact with the build as what we’ll call a ‘build operator’. They are a Java developer who wants to compile and test the sources, generate project documentation, and so on. The need not, and should not have to think about, look at, or modify build script internals in order to satisfy those core use cases. It should not be a matter of tribal knowledge, documentation, or previous experience that they know (remember) how to operate the build. Rather, they should have a friendly interface that can tell them what’s possible, and help them through their daily workflow.
As a related aside, those that create and maintain the build, we’ll call ‘build masters’. Of course, in practice, the roles of ‘build operator’ and ‘build master’ may be played by the same individual people, but it is nevertheless important to distinguish the user roles from the user. The build master is also naturally a power-user of this CLI, but spends much of their time interacting with the Gradle DSL and APIs to implement requirements in the build script(s).
Build systems need not be overly rigid. To constrains what’s possible in the name of ‘build homogeny’ would indeed be nice if it weren’t for the pesky reality that not all builds are the same, and that build heterogeny is the reality and rule, not the exception. There are many specific standars in an enterprise that need to be explicitly modelled. In practice, too many constraints forces the users to make what would be explicit concepts implicit. This makes the build harder to operate.
The proper solution to the apparent homogeny (consistency) vs. heterogeny (flexibility) problem is to provide build operators with a helpful UI. If build A differs from build B, this is not a problem if they each present to me a clear understanding of what I can do and why I would care.
What will this UI look like? It will be fiercely minimalistic yet always friendly, offering to tell you more about what you specifically care about. It will be in color by default, with an option to disable. We think color makes a tremendous difference at the command line, and again defer to Git and Roo as all the proof necessary. Gradle will provide advanced bash-completion scripts capable of staying up-to-date with the dynamic nature of individual gradle builds. Unlike Git, Gradle’s bash-completion support will be a first-class member of the Gradle ecosystem; something that can be installed by default / on demand and in a hands-free fashion.