Document task-specific switch feature

Details

  • Type: Bug Bug
  • Status: Open Open
  • Resolution: Unresolved
  • Affects Version/s: 1.0-milestone-3
  • Fix Version/s: None

Description

The task-specific switch syntax of Gradle is undocumented.

USAGE: gradle [option...] [task...]

That syntax message is just, as it does not allow for "gradle tasks --help". Note that there is a switch after the task name.

More important for me personally is, how do I code targets to detect and make use of these task-specific switches?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Adam Murdoch added a comment -

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.

Show
Adam Murdoch added a comment - 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.
Hide
Permalink
Adam Murdoch added a comment -

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).

Show
Adam Murdoch added a comment - 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).
Hide
Permalink
Blaine Simpson added a comment - - edited

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.

Show
Blaine Simpson added a comment - - edited 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.
Hide
Permalink
Blaine Simpson added a comment -

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".

Show
Blaine Simpson added a comment - 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".
Hide
Permalink
Blaine Simpson added a comment -

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).

Show
Blaine Simpson added a comment - 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).

People

  • Assignee:
    Unassigned
    Reporter:
    Blaine Simpson
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: