Why was custom object support removed from file() and files() in milestone 9?


(andrew.oberstar) #1

As far as I can tell, we aren’t using this functionality, but I was wondering about the reasoning behind this change. This seems like a nice bit of flexibility. There are other places (namely the version property) where you allow arbitrary objects, on which toString() is called before the value is used, so this seems a little inconsistent.

Side note: The DSL reference should reflect that passing an arbitrary object to file() is deprecated. The project.file() documentation still implies this is a supported option.

From the migration guide:

Passing custom objects to Project.file() and Project.files() > Passing parameters to Project.file() or Project.files() of a unrecognized type is now deprecated. In the past, any object instance could be passed and Gradle converted this object to a File reference using new File(.toString()).

Passing custom objects to Task.dependsOn() > Passing objects to Task.dependsOn() of other type than the explicit supported and documented is now deprecated. In the past, any object instance could be passed and Gradle mapped this object to a task dependency using toString()).

And from the DSL:

File file(Object path) > Resolves a file path relative to the project directory of this project. This method converts the supplied path based on its type: > * File. If the file is an absolute file, it is returned as is. Otherwise, the file’s path is interpreted relative to the project directory. > * URI or URL. The URL’s path is interpreted as the file path. Currently, only file: URLs are supported. > * Closure. The closure’s return value is resolved recursively. > * Callable. The callable’s return value is resolved recursively. > * Object. The object’s toString() value is interpreted as a path. If the path is a relative path, the project directory will be used as a base directory. A String starting with file: is treated as a file URL.


(René Groeschke) #2

Hello Andrew, first of all thanks for your feedback. We noticed, that allowing custom objects for Project.files and Project.file() often caused unexpected or misleading behavior in gradle. One example for this is GRADLE-2072. We want to get a bit stricter here, to fail fast and give the user better feedback here.

I’ve updated the Javadoc for Project.file and Project.files this morning and unfortunately these changes didnt’t make it to the snapshot and into the snapshot DSL.

regards, René


(Luke Daley) #3

Longer term there will be a formal mechanism for plugging in custom type transformations, so you’ll be able to specify how your custom types should be coerced.


(andrew.oberstar) #4

Ah… That issue clears it up for me. Thanks for the explanation.


#5

I think it’s good when our release notes/migration guide provide details of the motivation behind a change, particularly the removal/deprecation of existing features. When people notice that their build suddenly starts emitting deprecation warnings, they may go to the release notes to find out why.


(René Groeschke) #6

@Daz good point.