On 07/10/2011, at 3:31 AM, Luke Daley wrote:
> Hi,
>
> We now handle passing the clients stdin to the build daemon. This means we
> have to do some swapping around of System.in. I can see that at some point
> someone is going to want to do their own System.in swapping and this is going
> to break our strategy.
>
> A case might be the use of some library that a user wants to integrate that
> insists on reading from stdin and they want to pipe their own data (say from
> a file) to this utility. The first thing they will reach for is
> System.setIn().
>
> What we could do is provide a project method that takes an InputStream and a
> Closure that we make work with our strategy. e.g.
>
> withInput(new FileInputStream(file("input-for-library")) {
> new SomeLibrary().readStdin()
> }
Why not this:
def original = System.in
System.in = new FileInputStream("...")
try {
new SomeLibrary().readStdin()
} finally {
System.in = original
}
>
> It's an edge case to be sure, but it seems like we should make it work now
> while adding stdin support to the daemon.
I think we should wait for a use case for this, particularly given that this is
completely doable with some regular code like the above.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
