On 10/02/2012, at 1:10 AM, [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.
Right. I missed the getFileResolver() method. We would probably just get rid of it from a public FileOperations 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 > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
