Access build tools resources

[alpar-t]

The build plugin now adds a task to write out specific resources meant for consumption to the file sustem.

exportBuildResources {
    resource 'checkstyle_conf', "$buildDir/checkstyle.xml"
}

The task is not ran by default, the tasks that need the files should depend on it.
Will update existing uses in checkstyle and look for others in a subsequent PR.

Came out of a discussion following #31989.

[elasticmachine]

Pinging @elastic/es-core-infra

[rjernst]

@atorok Thanks for getting started on this. Accessing resources from build tools is something we do in many places in our build, but it has created a spaghetti network of implicit cross project dependencies, and formalizing these will be great for ensuring our gradle plugin continues to work externally.

I have 2 general comments so far:

• I don't think we need to be so strict as to require every file accessible be explicitly defined in build-tools. Any build file can always do BuildPlugin.class.getResourcesAsStream, so having the extra work to "whitelist" the files allowed just makes getting to new files added cumbersome.
• How do you envision tests actually using this task? It looks like a number of steps would be necessary, including creating a local path, specifying the file to copy in this new task, adding a task dependency, and using the local file path in the task consuming the file. Is there a way we can reduce the amount of boilerplate necessary?

[alpar-t]

I wasn't 100% sure on the white-listing either, will remove it.

We could add conventions to reduce the boilerplate.
If we have a pre-configured output directory and always export there to the same path as provided, then one just has to configure the newly added task to export a specific file and declare a dependency on it.
If we want to avoid specifying the file to export, we could create a list of resources at build time and include it into the resources, so that the task would know what all the resources are and always export all of them, but not sure we should do that. We might be able to go away with the explicit dependency using lazy configuation I haven't used this one before, but I will take a look at how we can use it.
If we could have the newly created task expose providers for specific files so that by writing something like task example { doLast { println "using: " + buildTools.resource('foo/bar').get() } } would configure the export task to export the specified file and imply a dependency to it from the example task, it would be very nice to use.

[alpar-t]

I found gradle/gradle#3811 which has some more insight into why some of the lazy configuration doesn't work.

[alpar-t]

@elasticmachine test this please

[alpar-t]

@elasticmachine test this please

[alpar-t]

@rjernst this is ready for another review
@elasticmachine test this please

[alpar-t]

Use other files, e.x. forbidden APIs to avoid confusion.

[alpar-t]

Rename task to buildResources and method to use

[rjernst]

LGTM. One suggestion: change "exportBuildResources" to "buildResources" and then the method to "use", so it looks more like a normal DSL.

[alpar-t]

it's buildResources.take as use is a keyword in Groovy. Let me know if you have an idea for a better verb.

[rjernst]

@atorok I don't think take is a good term here. It has both negative connotations and doesn't accurately portray what the buildResources task is doing (it isn't taking resources away). We previously discussed having the task containing "copy" in the name, but you did not want it confused with the gradle copy task. However, I think the inner part of the dsl here could be copy? That is technically what it is doing, copying a resource for local consumption.