Any improvements to console input/output in m8 and recent releases?

Old Forum Archive
1

A couple of relevant threads/jiras on the subject:

For this specific case I would like to be able to query the user executing the gradle build for a license acceptance using a command line console prompt, but the question is more generic:

  • How should we go about programmatically outputting text to the build console without polluting the output with the gradle status logging (status logging as in “Building>”, “Resolving dependencies>”. Programmatically meaning sending in -q on the command line is not enough) * How should we go about retrieving user input from the build console when the build is run by the gradle daemon. With the recent (and brilliant, many thanks and cudos to the dev team) changes and improvements to the gradle daemon, almost all our builds are now run in daemon mode which elevates the priority of this issue.
2

How should we go about programmatically outputting text to the build console without polluting the output with the gradle status logging (status logging as in “Building>”, “Resolving dependencies>”. Programmatically meaning sending in -q on the command line is not enough)

I don’t quite understand what you are after here. What kind of output do you want to display?

How should we go about retrieving user input from the build console when the build is run by the gradle daemon. With the recent (and brilliant, many thanks and cudos to the dev team) changes and improvements to the gradle daemon, almost all our builds are now run in daemon mode which elevates the priority of this issue.

You can read from ‘System.in’ and everything will work fine (the daemon infrastructure will forward the input). The Java 6 console is not supported yet, so “secure input” is still a bit awkward. If you need to solve this, I suggest having the user write the secure content to a tmp file and asking the user for the path to the file.

3

For the first case I am after the functional equivalent of the following groovy code:

def result = System.console().readLine("Accept license [y/n]: ")

where the user is presented with a prompt and can respond to it. Not sure if this is still the case, but at least a few versions back (and as documented in GRADLE-1147 etc) trying to do a combination of say println and reading from system in caused the gradle progress logging to inject tings in between. So you end up with the following prompt to the build user:

Accept license [y/n]:
> Loading

which becomes:

Accept license [y/n]:
> Loadingy

once the prompt has been responded to.

4

Quick follow up. With m8 the following build file:

task prompt << {
  print "Accept license [y/n]: "
  def result = new Scanner(System.in).useDelimiter(System.properties['line.separator']).next()
      println ""
  println "Result: $result"
}

gives the following result before input:

$ gradle --daemon prompt
Note: the Gradle build daemon is an experimental feature.
As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
> Building > :prompt

and after input:

$ gradle --daemon prompt
Note: the Gradle build daemon is an experimental feature.
As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
> Building > :prompty
:prompt
Accept license [y/n]:
 Result: y
  BUILD SUCCESSFUL
  Total time: 2 mins 14.69 secs

Changing the print to a println gives:

nadurra:prompt mbjarland$ gd prompt
Note: the Gradle build daemon is an experimental feature.
As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
:prompt
Accept license [y/n]:
 > Building > :prompt

which is somewhat better, but still not optimal. I know I can do “-q” on the command line to turn off progress logging, but as discussed in previous threads since -q is not the default behavior and almost none of the target users will be using -q for every build execution, expecting them to do -q before they even know there is going to be a prompt does not quite solve the issue…which is why I was hoping for a programmatic way to solve this.

Oh…and thank you! Reading from system in works like a charm. Unfortunately System.in doesn’t have the Console method readLine which combines the prompting with the reading and gets rid of the injected logging issue.

5

Right, I see.

This hasn’t changed, and is not scheduled to be improved for 1.0.

6

For a bit of comic relief and an actually working (albeit heinously ugly) solution to the prompting issue, you can do the following:

task "Accept License [y/n]: " << {
  def result = new Scanner(System.in).useDelimiter(System.properties['line.separator']).next()
  println ""
  println "Result: $result"
}

which will give the following more or less desired console:

$ gradle --daemon
Accept
Note: the Gradle build daemon is an experimental feature.
As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
  > Building > :Accept License [y/n]: y
:Accept License [y/n]:
   Result: y
  BUILD SUCCESSFUL
  Total time: 10.403 secs
7

As it has been a few releases and a number of months I figured this was worth revisiting. Any plans or existing solutions for the console logging and user input issue above? The goal being to be able to provide clean user input prompting even without the ‘-q’ flag and when using the daemon, i.e.:

$> gradle myTask
...
Accept license agreement [y/n]:
y
...

a quick tour through jira and the forum came up with the fowllowing:

GRADLE-2310 GRADLE-1147 GRADLE-1168 standard in when using the daemon

also the templates plugin still seems to be using System.console():

TemplatesPlugin.groovy

which I assume will break when using the daemon.

Using std in as suggested in the forum post still leaves the progress prompting polluting the output, i.e. something like (untested):

$> gradle myTask
...
Accept license agreement [y/n]:
  >myTasky
...

Any thoughts?

8

Better console support is in the queue, but not a priority for 1.5.