Right now, we publish each Maven artifact "cluster" -- for "logins",
say, that is "logins", "logins-withoutLibs", and "logins-forUnitTests"
-- to a single bintray package named like the Maven artifact ID (say,
"logins").
This seems to be common, but bintray mirrors packages to jcenter, and
bintray packages don't map directly to Maven coordinates. AFAICT,
that is the thing that requires somebody (right now, me -- nalexander)
to push the "mirror to jcenter" button in the bintray UI.
If we instead have a single bintray "package" (say,
"org.mozilla.appservices") and then publish many Maven artifacts to
that package, we should get automatic jcenter mirroring for everything
that we have under it. Let's try!
This is necessary to make Development with the Reference
Browser (https://mozilla.github.io/application-services/docs/applications/working-with-reference-browser.html)
smooth.
This was hard because the new kapt feature in 3.2.0+ interacts badly
with configuration resolution, and we were triggering resolution
earlier than the plugin could accommodate. This is a generally
challenging thing to manage in Gradle, with confusing side effects;
this is one such confusing side effect! See the in-code comments for
the details, which can't be left to a commit message.
This was intended to work around a bintray publishing issue, but it
didn't work. So let's return to
`org.mozilla.places:places-{forUnitTests,withoutLib}` rather than
`org.mozilla.places-{forUnitTests,withoutLib}:places-{forUnitTests,withooutLib}`.
This will matter more when we publish to maven.mozilla.org, which is
prefix based.
This plugin version splits the "default" target into named Rust
targets, and the passes through specially named environment variables
to allow configuring cross compilers. This allows us to produce
binaries for macOS in automation.
This adds an Android build type that does not include the Rust native
libraries and publishes it. The composite projects then arrange to
depend on these `-withoutLib` variants, there-by capturing the
Java/Kotlin code (and any future Android resources or assets) and any
transitive dependencies, but substituting their own libraries.
There's no way to "turn off" the parts of the `rust-android-gradle`
plugin that integrate the Rust libraries into the Android build, so we
do some manual `jniLibs` rewriting to achieve the same end. (Features
like this in the plugin are tracked in
https://github.com/ncalexan/rust-android-gradle/issues/23).
The new publication has different Maven coordinates, like
"org.mozilla.places:places-forUnitTests" so that consumers can augment
their unit test configurations, like
```
dependencies {
implementation 'org.mozilla.places:places:0.10.0'
testImplementation 'org.mozilla.places:places-forUnitTests:0.10.0'
}
```
and get the additional JNA libraries and Rust native code libraries in
their unit tests mostly transparently.
Right now only the "default" target's native libraries will make it
intot he new Maven publication; broadening the set of targets here
will require expanding the rust-android-gradle plugins set of targets
so that it can cross-compile for multiple desktop architectures and
not just multiple Android architectures. That's follow-up to this.
This will interact with megazord/composite libraries as well, but I
expect that the same process of dependency rewriting and unification
will extend to the additional "-forUnitTests" dependencies smoothly.
The real advantage here is that the newer `maven-publish` plugin has
some support for multiple publications in a single Gradle project, and
we need that:
- for unit test specific archives (native code built for desktop hosts)
- for component libraries that don't have native libraries but are
glued together into composites
This just paves the way for those changes.
There are two project layouts possible. One is that each sub-project
is its own Gradle project with its own copy of the Gradle wrapper,
project configurations, etc. The other is that there's one
multi-project with sub-Gradle projects.
Generally the multi-project approach, even for decoupled projects, is
simpler. The `android-components` repository uses it, even though its
projects are very explicitly decoupled in most cases.
Nick Alexander