Task-specific command-line options are an internal feature for now. We will provide a public interface for them at some point in the future, probably after the Gradle 1.0 release.

Having said that, if you're happy to use an internal feature (which may change), you can attach a @CommandLineOption annotation to a task property setter to make that property available as a command-line option.

Currently, it only works with properties of type boolean, and only with setter methods (eg not on groovy properties).

I checked the Gradle source code and I see that this needs to be done in Java. No problem with the Java, as I have much more experience with Java than with Groovy, but the risk and maintenance for carrying around .class customizations isn't acceptable for my project.

I needed to override the "tasks" target for some important reasons, but I will just have to leave my current work-around in place, where I emulate gradlew tasks --all with gradlew -PallTasks=true tasks.

Thanks for the information and advice.

I see that Jira doesn't let me edit the Issue's Description.

I wrote the wrong switch there. The existing task-specific switch is "gradle tasks --all", not "gradle tasks --help".

Nothing said here contradicts that the in-program and user guide documentation is wrong where it does not allow for task-specific switches.

I think that rather than correcting the documentation and help text, you should enhance the "tasks" implementation to not require a quirky and singular syntax. It's counter-productive when trying to educate people about Gradle syntax when you also instruct them to give a command violating the stated rules. Just check for a boolean build property so that people can use the same exact functionality with advertized, public, and general Gradle usage. (Like I described with my usage of the allTasks property above).

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!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.