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.
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. Andrew Oberstar From: Adam Murdoch <[email protected]> To: [email protected] Date: 02/08/2012 04:41 PM Subject: Re: [gradle-dev] Making FileResolver public. On 09/02/2012, at 5:30 AM, Luke Daley wrote: I think we should make FileResolver public, and also project.getFileResolver(). The thing that is currently FileOperations might be a better candidate, as it represents the 'file DSL'. Here's what I would do: * Rename FileOperations to something else, as it needs a better name (not sure what that name is). * Move FileOperations to o.g.api.file * Change Script to extend FileOperations * Add Project.getFileOperations() * Deprecate the Project methods that are now available via Script (API deprecation, not DSL deprecation). And later * Bust up FileOperations into a few chunks (what is currently FileResolver might become one of those chunks). * Remove the file DSL methods from Project. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
