[DATAFU-185]fix(build): resolve rat license-check paths against project root

[InbalHoni]

The :rat task used relative paths, which the Gradle daemon's embedded Ant builder resolves against the daemon working directory (~/.gradle/daemon/5.6.4/) instead of the project root - so it scanned the wrong directory and could not find the report stylesheet, failing ./gradlew clean assemble.

Switched to absolute paths (project.projectDir / project.buildDir). Verified assemble now passes with :rat succeeding.

Also added the missing Apache license header to .asf.yaml, which :rat flagged as an unknown license.

JIRA: https://issues.apache.org/jira/browse/DATAFU-185

[eyala]

Interesting, I don't see this occurring on my computer, but I do see this line in our Actions CI report:

> Task :rat
Unknown license: /home/runner/work/datafu/datafu/.asf.yaml

Is this what you were trying to solve?

[InbalHoni]

Interesting, I don't see this occurring on my computer, but I do see this line in our Actions CI report:

> Task :rat
Unknown license: /home/runner/work/datafu/datafu/.asf.yaml

Is this what you were trying to solve?

The unknown license is one side effect of the relative paths, while the report stylesheet is another. The root cause is that the rat.gradle used relative paths, and so the Ant builder resolved them against the daemon's working directory rather than the project root. For you it was scanning /home/runner/work/datafu/datafu/.asf.yaml instead of scanning the project, and for me it scanned the daemon's log files (I got unknown license for daemon/5.6.4/daemon-80058.out.log on top of the stylesheet issue). Maybe I'll fix the PR/commit message and mention these side effects as a result of relative paths. wdyt?

[eyala]

Yes, if you change the commit message, that will retrigger the CI and we will be able to see whether the ant warnings disappear. I've opened a JIRA issue for it, you can change the commit message to use DATAFU-185 as a prefix.

[InbalHoni]

@eyala so I did some further investigation into this with attempts of building with/without this change, and actually I think these are two separate things, let me reiterate this issue:

1. The stylesheet error I had actually failed the rat task - I got an actual failure with

Execution failed for task ':rat'.
stylesheet /Users/ihonigman/.gradle/daemon/5.6.4/gradle/resources/rat-output-to-html.xsl doesn't exist.)

This stemmed from the attempt to build in my local environment - in this local environment, the lack of absolute paths lead to the daemon searching in the working directory instead of project root. The stylesheet issue is also what failed my build, not the unlicensed log file.

2. The unknown license issue - in my case you can see it has the same path problem since its root is the same wrong gradle/daemon/5.6.4/ base as the stylesheet. In your case, the base is true - /home/runner/work/datafu/datafu/ - it is the project's root, and it doesn't fail the rat task. I think the problem with the .asf.yaml file, might be that it genuinely doesn't have an Apache license header (you can see it appears from the moment the CI went back to working again here), I think if we add the header at the top of the .asf.yaml file this line will also go away (andit also alignswith ASF's conventions). Want me to add it in this PR?

[eyala]

Yes, I'm realizing now that I approved the addition of the .asf.yaml file a little while ago when our CI was down, and I didn't notice the rat warnings in the logs. I think adding the license to this file as well as the original change is a good idea.

[InbalHoni]

@eyala added the license header to asf.yml.

Verified with a controlled check on this branch, toggling only the header - with it, there are no warning and rat reports .asf.yaml as

license-approval=true, family "Apache License Version 2.0"

Without it, we get:

license-approval=false / ?????

and the Unknown license line returns.

I Also got a green CI run in my fork (which was enabled by the recently added workflow_dispatch 🙃).