docs(README): update the Gradle section

[borisrizov-zf]

Summary

The bash version using grep is inconsistent, that's why an extensive Gradle version, written in Groovy, is used to download the dash.jar resolve all dependencies and run the Dash tool on them.

This allows for usage in ci/cd environments as the task will fail if the Dash run fails.

[wba2hi]

Suggested change

	logger.lifecycle("Removing 'dash.jar'")
	file('dash.jar').delete()
	logger.lifecycle("Removing 'deps.txt'")
	file('deps.txt').delete()
	doLast {
	logger.lifecycle("Removing 'dash.jar'")
	file('dash.jar').delete()
	logger.lifecycle("Removing 'deps.txt'")
	file('deps.txt').delete()
	}

Should be wrapped inside a doLast-block so it is not executed during configuration phase

[wba2hi]

Suggested change

	filtered.each { logger.quiet("{}", it) }
	sorted.each { logger.quiet("{}", it) }

typo?

[wba2hi]

optional: can we rename the file to dependencies.txt pretty please? :) If yes, keep in mind to rename all occurrences in all files

[wba2hi]

Suggested change

	dasj.jar
	dash.jar

typo

[wba2hi]

rootProject build.gradle or app / lib build.gradle? I guess you mean the rootProject build.gradle here as you also call it with without a project here

[wba2hi]

Is this really needed?
You don't resolve the Dash License Tool using a maven dependency but by downloading a file via url

[wba2hi]

a different location would be preferable, e.g. $rootDir/build/oss

Advantage: It would automatically be cleaned with a ./gradlew clean

[wba2hi]

Functional Findings:

• optional: encapsulate the code in a separate gradle file (e.g. dash.gradle) and just apply the script where needed (rootProject, subprojects, both...) - it's cleaner than "polluting" the build.gradle with different contexts and different tasks. However it might get a bit finicky with the plugin you apply, as you can't use the plugin-block in other gradle scripts than settings.gradle and build.gradle
• when executing dashDependencies not on the rootProject but on a subproject the results will contain an entry like this: project :app. These entries should be excluded from the dependencies and therefore not be part of the dependencies.txt
• right now the dashDependencies task is only executed on the rootProject, however each subproject will have it's own dependency tree and configurations. Basically you need to create and execute your task for each subproject, similar like this:

subprojects {
    tasks.register('dashDependencies') {
        description = "Output all project dependencies as a flat list and save an intermediate file 'deps.txt'."
        group = 'License'

        doLast {
            def deps = []
            project.configurations.each { conf ->
                if (conf.canBeResolved && conf.getName() != 'archives' && conf.getName() != 'default') {
                    deps.addAll(conf.incoming.resolutionResult.allDependencies
                            .findAll({ it instanceof ResolvedDependencyResult })
                            .collect { ResolvedDependencyResult dep ->
                                "${dep.selected}"
                            })
                }
            }
            def sorted = deps.unique().sort()
            mkdir "$rootDir/build/oss/${project.name}"
            file("$rootDir/build/oss/${project.name}/dependencies.txt").write(sorted.join('\n'))
        }
    }
}

Execute ./gradlew dashDependenciesand check the results for each submodule here: $rootDir/build/oss/. All of them should be clarified using the dash license tool. It's better to scan to much than scanning to few :)

[wba2hi]

we have something similar in place here (we don't scan with gradle, we just provide the dependencies.txt for the CI):

• dash.gradle.kts
• dash.sh
• build.gradle.kts

Besides the few "project"-entries the recognition of both our scripts is on the same level (if executed on all subprojects). However I prefer your way of collecting the dependencies, because it's less error prone than using the regular expressions to parse them.

Maybe you can pick the best of both our worlds so we get something that is top-notch :)

Once its more fine-tuned we will definitely use it in favor of our dash.sh in our project.