While I do see a need, I don't think this is the solution.

• It is android only
• It only copies a file => Use Copy Task
• There is no need to copy the file at all => just wire the output of licensee to the android resources
• The task does not need this input

=> I am okay to wire the outputs of the task to the android resources, even by default if R8/D8 can remove the file if unused.

But if we do want to make the internal json file public available, we should also implement #410 to read the file. Or what is the real use-case? Should the user see the JSON file as is?
Or do you want to show it with some UI? Then you need parsing at all.

=> Or licensee could generate Kotlin code directly.

While I do see a need, I don't think this is the solution.

• It is android only
• It only copies a file => Use Copy Task
• There is no need to copy the file at all => just wire the output of licensee to the android resources
• The task does not need this input

=> I am okay to wire the outputs of the task to the android resources, even by default if R8/D8 can remove the file if unused.

But if we do want to make the internal json file public available, we should also implement #410 to read the file. Or what is the real use-case? Should the user see the JSON file as is? Or do you want to show it with some UI? Then you need parsing at all.

=> Or licensee could generate Kotlin code directly.

What is the problem being android only? we support android specific stuff already.
I don't think so we wanna get into the business of parsing JSON files neither generating Kotlin code. We are providing a way for users to consume the JSON file as they see fit.
What do you think @JakeWharton ?

@jgbirk Like I said, I am okay to wire the outputs of the task to the android resources. But there is no need for a copy task, just use variant.sources.assets!!.addGeneratedSourceDirectory(task, LicenseeTask::outputDir).

But I still don't understand the real use case. The end user of the app will see the json file as it? That's very uncommon.

@jgbirk Like I said, I am okay to wire the outputs of the task to the android resources. But there is no need for a copy task, just use variant.sources.assets!!.addGeneratedSourceDirectory(task, LicenseeTask::outputDir).

But I still don't understand the real use case. The end user of the app will see the json file as it? That's very uncommon.

👍 Got it, I can do that.
Correct, I'm just making the file visible to context.assets.
We have our own open source view, where we will parse the JSON using Moshi and display it. Other users might decide to use GSON, etc.

@jgbirk

We have our own open source view, where we will parse the JSON using Moshi and display it. Other users might decide to use GSON, etc.

Now I got your use-case.
But to prevent loading and parsing the json file at runtime again, it was just an idea to not provide a (unstable) json file, that needs another Json library, we could generate Kotlin code with proper api instead.

variant.sources.assets!!.addGeneratedSourceDirectory(task, LicenseeTask::outputDir)

Maybe I'm missing something, but just that is not creating the file.

The reason for not using variant.sources.assets!!.addGeneratedSourceDirectory(task, LicenseeTask::outputDir) here is that outputDir contains both artifacts.json and validation.txt. Since validation.txt is useless for users, they would still need to exclude it using android.packaging.resources.excludes or a similar mechanism. I added a similar copy task logic at https://github.com/LawnchairLauncher/lawnicons/blob/815f9f21522545449eb1b1b78bf9c8f59f80f7bc/app/build.gradle.kts#L112-L125.

androidComponents.onVariants { variant ->
    val capName = variant.name.replaceFirstChar { it.titlecase(Locale.ROOT) }
    val licenseeTask = tasks.named<LicenseeTask>("licenseeAndroid$capName")
    val copyArtifactsTask = tasks.register<Copy>("copy${capName}Artifacts") {
        dependsOn(licenseeTask)
        from(licenseeTask.map { it.jsonOutput })
        // Copy artifacts.json to a new directory.
        into(layout.buildDirectory.dir("generated/dependencyAssets/${variant.name}"))
    }
    variant.sources.assets?.addGeneratedSourceDirectory(licenseeTask) {
        // Avoid using LicenseeTask::outputDir as it contains extra files that we don't need.
        objects.directoryProperty().fileProvider(copyArtifactsTask.map { it.destinationDir })
    }
}

The reason for not using variant.sources.assets!!.addGeneratedSourceDirectory(task, LicenseeTask::outputDir) here is that outputDir contains both artifacts.json and validation.txt. Since validation.txt is useless for users, they would still need to exclude it using android.packaging.resources.excludes or a similar mechanism. I added a similar copy task logic at https://github.com/LawnchairLauncher/lawnicons/blob/815f9f21522545449eb1b1b78bf9c8f59f80f7bc/app/build.gradle.kts#L112-L125.

androidComponents.onVariants { variant ->
    val capName = variant.name.replaceFirstChar { it.titlecase(Locale.ROOT) }
    val licenseeTask = tasks.named<LicenseeTask>("licenseeAndroid$capName")
    val copyArtifactsTask = tasks.register<Copy>("copy${capName}Artifacts") {
        dependsOn(licenseeTask)
        from(licenseeTask.map { it.jsonOutput })
        // Copy artifacts.json to a new directory.
        into(layout.buildDirectory.dir("generated/dependencyAssets/${variant.name}"))
    }
    variant.sources.assets?.addGeneratedSourceDirectory(licenseeTask) {
        // Avoid using LicenseeTask::outputDir as it contains extra files that we don't need.
        objects.directoryProperty().fileProvider(copyArtifactsTask.map { it.destinationDir })
    }
}

Yep, that served me as inspiration for this!

Been thinking about this over the weekend, although I did think about this originally when the tool was built.

My original intent was to parse this in a build plugin specific to our app, and either write out a new different JSON format or to generate Kotlin directly in the shape of our existing screen. The reason I wanted to do this was so that we could massage the data to look nicer while retaining the ability to fail the build if something was completely absent.

One of the ways our Open Source attribution screen looks better than others is that it's far more human readable and using logical groupings of artifacts rather than a simple linear display. For example, we could choose to put com.squareup.* under "Square" and app.cash.* under Cash App, or we could choose to put both plus xyz.block under the bland, plain white bread, boring-ass "Block" name.

Now we could simply embed the raw JSON and do all of this at runtime. There are no real performance or size concerns either way. We would lose the ability to fail the build if someone adds a dependency for which there is missing human-friendly data, though, although we obviously can always fall back to the machine data.