Due to use of Unity-as-a-Library we have an Android library module / Gradle subproject that has a number of AAR (Android archive) files in its "libs" directory.
We have been using the com.github.kezong:fat-aar Gradle Plugin (https://github.com/kezong/fat-aar-android/) to aggregate all of this into a single AAR result for the module, which works great, but:
- This plugin is no longer maintained
- It is not compatible with Gradle 8+
So instead we are looking for a way to:
- Publish all of these AARs to a Maven repository as part of the publishing for this module (call this Gradle project "Child")
- This seems easy enough...
- Have one "parent" library subproject (call this Gradle project "Parent") within the same Gradle root project that depends on the normal AAR output of this subproject plus all of the AARs in (1)
- Express this dependency such that "Parent" uses local artifacts from "Child" when building in the same root project, but when "Parent" is published to Maven it expresses these dependencies in terms of the appropriate Maven artifacts from (1).
- Ensure that other subprojects using the "parent" subproject only need to depend on "Parent" project, without mentioning any of the AARs it in turn depends upon
Apart from the extra AARs, this is the situation we have today with fat-aar -- and we're trying to reattain it. Essentially we want the normal subproject vs. remote Maven dependency dualities to be properly handled for the extra AARs in addition to the "main" AAR for the project.
We've tried various convolutions from https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:simple-sharing-artifacts-between-projects and https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing_custom_artifacts_to_maven -- so far to no avail.
How can this be achieved?
In the very worst case, we could:
- Publish the extra AARs from "Child"
- Manually override/replace Child's POM to include these extra AARs
- Manually add dependencies on each of the extra AARs (by direct file reference) to all other subprojects under the same root project
But (2) would be regrettable and (3) would be an ongoing source of pain.
