Before, we always ran the "generate JNI wrappers" command and had the
command be smart about updating the output. Now we move the smarts to
the Gradle side to streamline the build.
Differential Revision: https://phabricator.services.mozilla.com/D12795
--HG--
extra : moz-landing-system : lando
I'm not sure how this ever worked in the `android-gradle-dependencies`
task -- it must have been because of `--continue`.
Differential Revision: https://phabricator.services.mozilla.com/D12793
--HG--
extra : moz-landing-system : lando
Before, we always ran the "generate JNI wrappers" command and had the
command be smart about updating the output. Now we move the smarts to
the Gradle side to streamline the build.
Depends on D12794
Differential Revision: https://phabricator.services.mozilla.com/D12795
--HG--
extra : moz-landing-system : lando
I'm not sure how this ever worked in the `android-gradle-dependencies`
task -- it must have been because of `--continue`.
Depends on D12792
Differential Revision: https://phabricator.services.mozilla.com/D12793
--HG--
extra : moz-landing-system : lando
Right now we skip generating natives binding for a class if the class
doesn't have native methods. However, we should still generate the
natives binding for JNIObject classes because these classes can still be
attached to C++ objects even without native methods.
Differential Revision: https://phabricator.services.mozilla.com/D7106
--HG--
extra : moz-landing-system : lando
This allows us to invoke AnnotationProcessor more than is strictly
necessary and not trigger expensive native code compilations unless
the native code has actually evolved.
MozReview-Commit-ID: H1BIzJsdyIh
--HG--
extra : rebase_source : 30851f5561d3bc044f2245af5b68bd6f038995dd
We want annotationProcessors to be compiled and archived into a JAR at
build time, ready to generate JNI wrappers. (That is, until we turn
the whole thing into a real annotation processor.) But even if we do
use a real annotation processor, we still need to generate SDK
bindings, which is less clearly expressed as an annotation processor.
(It's more of a build step.)
Gradle provides a huge number of ways to organize build logic to
achieve this: see
https://docs.gradle.org/current/userguide/organizing_build_logic.html.
Unfortunately, the best such way -- putting the code into
$topsrcdir/buildSrc -- has key disadvantages:
1) it pollutes the top-level $topsrcdir, and there's no way to change the
location of buildSrc (https://github.com/gradle/gradle/issues/2472);
2) it's complicated to have a dependent project
(mobile/android/annotations) expose its code via a buildSrc project;
3) using buildSrc at all appears to conflict with the Android-Gradle
plugin version that we are using.
Therefore, this commit does something much simpler: it adds a
Java-only project and uses the resulting Gradle "Jar" task and archive
output as input to the existing Gradle "generate JNI wrappers" task.
MozReview-Commit-ID: 2OyYLPneE1M
--HG--
extra : rebase_source : d99b74a0a1e0bb3e8f4d4540978328388e5c2e42
Agi Sferro
Nick Alexander
Dorel Luca
Jim Chen