what provider gives me a

Provider<File>

? since this isn't valid

project.layout.file("diagrams/class.puml")

You give a relative path, to what should that relative path be relative?

yeah, that would work... not certain why files should be different from file 😉

why files should be different from file

I don't get what you mean by that

the api for

files

takes

Any...

It takes

Any

for historical reasons (pre-Kotlin DSL and pre-Providers) And iirc it documents that relative paths given to it are used relative to the project directory.

sure, point being is I can pass stringy paths and it did what I mean 😉

Ah,

layout.files

, I see. Yeah, it is defined in terms of

Project#files

and if a

FileCollection

is ok as result to work with further on probably is also ok, just a bit less explicit. 🙂

https://gitlab.com/Plunts/plantuml-gradle-plugin/-/issues/29#note_2403973823 in the event you should feel like elaborating on the wise of all of this to this guy... I feel like I'm terrible at explaining this stuff I especially don't understand all the virtues of the layout

... yes He just made exactly the syntax you requested possible by calling

asFile

for you: https://gitlab.com/Plunts/plantuml-gradle-plugin/-/blob/main/plugin/src/main/java/io/gitlab/plunts/gradle/plantuml/plugin/ClassDiagram.java#L51

Yeah, I didn't really look at the code but I was also talking about more than just those two calls. I was trying to incentivize the change to the entire system. However, I figured you might also explain why project.layout.projectdirectory is better than using file(). That's something I can't explain. I'm thinking that methods like writeTo for a signature are good but they should be backed by the property so that they don't evaluate until the task is evaluated. I'll see if I can't give him an example later, My publishing example is great 😉, But I might write a simple task that should demonstrate the difference between it being evaluated and not being evaluated until the task runs. Unless you happened to know some code that's easy to copy paste there

Well, as I described, if you for example have the file generated by another task, properly using `Property`s would preserve the task dependency while not doing so will loose the dependency even if there would be a

Provider

overload of the method. Having the function like that would mean you need to support all the possible variants like

File

,

RegularFile

,

Provider<RegularFile>

,

Provider<File>

, and any other possibility existing now or being added in the future. If it would be a

RegularFileProperty

, you could simply use everything the Gradle version you are using in the consumer project supports.

layout.projectDirectory

vs.

file()

per-se is not so much different, more depending on what the thing you try to configure expects / supports. The

layout

is mainly more explicit that you resolve a relative path relative to the project directory, but

file()

does the same and also documents that. When it comes to

layout.buildDirectory

or a

Provider<RegularFile>

things are different, because the project directory cannot change, the output path of a task property or the build directory can change.

I thought there was also something to do with relative versus absolute file path and build caching that went along with the layout object

I think relative and absolute paths would behave the same with both methods. How build cache is affected depends on the configured path sensitivity on the according task file input property.