A huge bonus would be supporting

gradle -D<Tab><Tab>

To see what properties are available to be set. For example, a user may not know about or remember the name for the -Dtest.single property (see GRADLE-1064). A quick tab completion would allow the user to discover that and much more. This is a marked improvement over Maven, by the way, which is all about magic Dflag strings like -Dsurefire.useFile=false, -Dmaven.test.skip=true, etc. It's fine that Gradle uses Dflags, but providing the user with a simple way to discover them will be great.

Fully agree. Although we see the -Dtest.single as a temporary solution anyway (which will continue to work!). To have more consistency we want to provide a generic mechanism to configure tasks via the command line by their API. Completion would still be awesome to have. But at least you don't have magic props any more. And using the API should also make it easier to provide a generic way to provide tab completion.

Excellent ideas. The GUI should make all this stuff discoverable too, and also provide auto-completion in the command text box.

I'm currently building a Bash completion for Gradle, I'll send a Pull request as soon as I'm finished. Currently I'm trying to get all available tasks. As I don't know Gradle internals yet, my current approach is to extract the tasks with a Regex from the output of

gradle tasks

, but of course that's an ugly way.

Is there a way to get all available tasks programmatically by using some kind of Gradle API?

@Ingo, you should use the tooling API: http://gradle.org/docs/nightly/userguide/embedding.html

@Ingo - glad to hear you're working on this. Good luck. @Adam, I would hope that any such solution could communicate with the Gradle daemon (if one is running). Is that implied in your comment about the tooling API? Is there any precedent yet for a non-gradle process communicating with the daemon? It's the only way I can imagine getting snappy performance out of the autocompletion process.

@Chris thanks! I have been thinking a lot about performance of the completion. My approach is to implement a small caching-mechanism for the completion.
It will cache the tasks (and other options) and update the cache in background when the buildfile changed. So there will never be a delay when the user hits the Tab key.

Yeah, the trouble is that it's hard to know "when the buildfile changed", as there could be any number of buildfiles having any variety of names, especially in a multi-project build. The need for a caching mechanism is obvious; I would suggest the Daemon is the natural place to do it as it has the opportunity to know everything already and be quite up-to-date when the autocompletion script queries it. Should be a perfect kind of service interface for you to get what you need without unnecessary hacks.

It's probably good timing for this too, given that the daemon will soon be out of it's 'experimental phase' (or so that's my understanding). This means that it's probably quite reasonable to expect that it already exists, or to trigger it's creation in the background.

Adam may have more input here...

In any case, even if you start out with something quick and dirty for caching, you'll be able to flesh out the actual autocompletion code in bash. I'd love to give it a try when you have something working!

@Chris, the tooling API uses the daemon. However, there are a few things that aren't quite right for the purposes of command-line completion:

• It will start the daemon if not running. We probably don't want this.
• It doesn't cache the model, so requesting the task model from the tooling api is currently about the same performance-wise as running 'gradle tasks'.
• Even with the daemon running, you have to pay the startup cost for the client jvm and daemon client (~400-800ms). Which is ok for building, but is probably too much for command-line completion. Interestingly, I did a spike of a native C daemon client a few weeks ago. It could run 'gradle tasks' for a single project build in ~100ms.

@Ingo, it would be much better if the caching and change detection happened in the tooling API or daemon, for a couple of reasons:

• IDEs and other tooling API clients can then take advantage of it.
• There are many, many potential sources of tasks in Gradle (plugins in buildSrc, apply'ed scripts, remote plugins, init scripts, and so on). Gradle itself (the daemon) is in the best position to know what the inputs to the build configuration are.

I'd suggest first just using the tooling API as is. It will do the job, but may not be super performant. Then, make it performant by improving the tooling API implementation, eg introducing caching.

@Adam: Makes sense to move caching to the daemon and just let the bash completion script use the tooling API as is.
But to have something working before caching mechanisms inside the daemon are implemented, I'll include the caching inside the completion script. This gives a feeling about how completion can be done in general and can later easily be removed.

I'm really curious how such a C daemon client looks like, I don't have any experiences with C->Java interaction yet. Would you mind publishing the sources?

@Ingo, the source is here: https://github.com/gradle/gradle/tree/native-client/subprojects/native-client. It needs some tweaks to the daemon to make it work (found in this branch), so it won't work with a vanilla Gradle daemon. It's also a spike, so I wouldn't go trying to use it to actually build anything. Should work on linux and mac.

@Ingo, did you ever publish your completion script? I've been looking for something like this.

@Eric its still in my Backlog. Thanks for reminding me. Will try to publish an initial solution this weekend and report here.

Come-on, come-on, publish a solution. This feature is sorely lacking.

This will really make the gradle adoption rate to increase a lot. Should be great if it works in the same way as spring roo and grails does.

Still nothing? this would be extremely useful..

Can this be used? https://github.com/devmop/gradle-bash-completion

I like the solution at https://gist.github.com/nolanlawson/8694399 as it does not require me to adjust my build files (and potentially build-files of third party projects)

I wrote a bash completion script with multi-project support:
https://github.com/ywelsch/gradle-bash-tools
Completion targets need to be manually updated (as this can take time in large multi-project builds).

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Benjamin Muschko I think it's still valid and actionable. All the requisite info should be there.

Announcing bash and zsh completion support for Gradle => git.io/gradle-completion