* Move cli around in preparation for askama and textwrap
* Add testing for the generated manifest.
* gradlew ktlint && detekt
* Cleanup target language testing
* Initial commit
* Skeleton code oracle and units-of-code for Kotlin
* Cargo.lock
* cargo fmt
* First cut of some incomplete stinking kotlin
* First feature has been generated, though no tests running
* Generating code, compiling it and testing it
* Change enums to work with kebab casing
* re-arrange testing infra to allow importing of static methods
* Add enum maps! Phew.
* Move enum map to structural
* Implement EnumMap and StringMap in terms of renamed MapCodeType
* Add list types
* Objects _almost_ done, but no passing in values from above.
* Move FeatureHolder into internal package
* Put in place guard rails re: object literals and merging
* cargo fmt / cargo clippy
* Add config file to specify package and nimbus object name
* Demoable for fenix homescreen
* Remove dead comments
* Add optionals
* Fixup testing scripts
Now we compile the runtime each time into a temp directory.
* Testing generated code
* Unit testing the code types
* Beef up the integration tests
* Cleanup: cargo fmt, clippy, and re-write some docs
* detekt
* Post rebase
* Detect kotlinc before running integration tests
* cargo fmt
This uses the new, cleaner factoring of our Android config from #4194
as an excuse to update some of our Android dependencies to bring them
inline with what's used in current android-components. It was much
easier than it has been in the past!
Prior to this commit, the gradle tasks for building and for testing
each component would depend on the "cargoBuild" gradle task of the
megazord, which means they would built it for all configured targets.
In TaskCluster we configure *seven* targets, so each `module-build-X`
TaskCluster job will build the full megazord seven times.
This commit makes two changes:
* Building the gradle package of a component no longer depends on
building the megazord at all. We doesn't actually need to the
Rust code built in order to package up the Kotlin files, and I
think this dependency was a hangover from when each component
used to build its own individual Rust library.
* Running the gradle tests of a component now depends only on
building the megazord for the native host platform, since that's
the only one that is actually needed for running the tests.
Given that we have 11 components that depend on the megazord,
each of which will now avoid building 6 useless copies of it
for non-native platforms, I expect this will save a total of
66 expensive `cargo build` invocations in a full TaskCluster run.
I've also included a few other tweaks to do less unnecessary
work in TaskCluster, which seem to save about a minute on the
much-more-common `android-build-pr` task.
Prior to this commit, each of our individual components had its
own copy of gradle logic for depending on the megazord, including
a couple of lengthy comments about fiddling around with JNA for
the Android Studio test runner.
I've moved all that logic into a helper function in `publish.gradle`
so that we can maintain it in a single location from here out.
There may be a cleaner or more idiomatic way to achieve this kind
of code-sharing in gradle, but I figure this *has* to be better
than our current copy-paste-based approach.
I've manually confirmed that a local `./gradlew test` completes
successfully, as well as testing via Android Studio.
We currently have four copies of the logic for calling UniFFI
from gradle, several with their own little tweaks. Let's take
the best lessons from each and consolidate them into a single
shared helper.
This version is, I think, an improvement over all the existing
ones:
* Like the nimbus version, it registers the task as generating
java source files, which should help things integrate cleanly
into the broader build.
* Like the fxa-client version, it declares explicit inputs so
that we can avoid re-running the task when nothing has changed.
* New in this version, it declares an input dependency on anything
that would affect the version of `uniffi-bindgen` that is in use,
since that too will change the generated outputs.
That last change should really help with smooth updates to the
version of UniFFI in use. Previously, if you changed the UniFFI
version it would not trigger a cleanup of old generated bindings,
and you'd get `java.lang.UnsatisfiedLinkError` errors like in #4054.
(This is UniFFI's last-line-of-defence measure to prevent you from
using bindings generated with one version of UniFFI on a library
compiled with another, which is very useful, but an extremely
confusing failure mode).
With this change, an updated version of UniFFI will invalidate
the gradle task that generates the bindings, causing them to
be regenerated with the new version.
The most important one is that we avoid publishing a new set of aars
if no code has actually changed. I'm not thrilled about the *way* we
accomplish it, but it works for me.
Our docs currently recommend two ways of building consuming apps against
local changes to this repo: an automated-but-perpetually-buggy composite build
workflow, and a reliable-but-tedious manual workflow of publishing to a local
maven repo.
This commit removes them both and replaces them with something similar to
the workflow used by android-components: some scripting to automate publishing
to and consuming from a local maven repo.
There where two issues. The most obvious is that the task name that
merges JNI libraries has evolved; it's now `merge{...}JniLibFolders`.
The second, which really caught me out, is that when both
`main.jniLibs.srcDirs` and `debug.jniLibs.srcDirs` contain the same
path, then the Android source set merger silently fails. I don't
really understand what's happening here, I just know that using only
`main.jniLibs.srcDirs` solves the issue.
Fixes#2659.
For inscrutable reasons, the various android packaging gradle tasks do
not get re-run when the underlying rust code changes. Something is not
correctly configuring gradle's up-to-date checks, but I've reached the
imit of how much time I'm willing to spend on figuring it out. Deleting
some intermediate files seems to force the tasks to re-run, and I was
not able to measure any increase in overall build time on my machine.
I don't like this, but I dislike it less than I dislike having to double-
check whether the rust code I have on disk the same as the rust code
compiled into my built artifacts.
Fixes#2659 (or at the very least, hacks its way around it).
Some of our consumers use this handy plugin [1] to automagically
include dependency license info in their app. By including our
own dependency license info in our .pom file we can make it
easy for those consumers to include correct license info for
all the transitive dependencies they pick up through us.
[1] https://github.com/google/play-services-plugins/tree/master/oss-licenses-plugin
This is required in order for stripping of debug symbols to work
correctly, since otherwise the gradle plugin doesn't know where
to find the appropriate `strip` command.
I've also added a very coarse test to ensure that the size of the
resulting release artifacts is sensible, which should help us check
whether this works in CI and guard against future regressions.
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.
jhugman
Ryan Kelly
Ryan Kelly
Nick Alexander
Thom Chiovoloni
Edouard Oger
Mitchell Hentges