Wouldn't you just want to add a withBaseDir() to FileOperations so you
could do project.fileOperations.withBaseDir() instead of having a
fileOperationsWithBaseDir() method?
file(Object parent, Object name) would be the equivalent to the idea of
new File(File/String parent, String name). Though I do prefer the idea of
adding withBaseDir to FileOperations. The main benefit you get from either
the two-arg file method or withBaseDir is that it allows you to resolve
the portions separately.
file("${parent}/${name}") will toString the components before going
through the normal file resolution. If parent happened to be a Closure,
this wouldn't work. I don't know how frequently that crops up, but it
does seem more flexible.
Andrew Oberstar
From: Luke Daley <[email protected]>
To: [email protected]
Date: 02/09/2012 08:42 AM
Subject: Re: [gradle-dev] Making FileResolver public.
On 09/02/2012, at 2:10 PM, [email protected] wrote:
If FileOperations is going to be made public as is, I would suggest that
FileResolver be made public at the same time. The public API shouldn't
have methods whose return type is an internal interface.
A quick look suggests that it might be best to make FileOperations public,
and change some of our to use FileOperations instead of FileResolver as a
gradual change as we promote more to the public space.
I'm thinking of things like DefaultSourceDirectorySet which should become
public before too long.
The main (and I think only) thing I use FileResolver for is the
withBaseDir method. Maybe adding a file(Object parent, Object name)
method would remove that need for me.
What would this do that's different to project.file("$parent/$name") ?
Rather than add this method, it might be better to be able to derive
FileOperations instances with different bases. So adding?
FileOperations fileOperationsWithBaseDir(Object base)
Then your above would be something like:
project.fileOperationsWithBaseDir(parent).file(name)
If we can manage I think we should go to 1.0 with public api for our
Object ? File logic.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
