This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
Print debugging a task that runs gradle has been really annoying as gradle
reads the output of 'mach environment' and fails as soon as a debug line shows
up.
What's worse, is it redirects stderr into stdout so even printing to
'sys.stderr' fails. This fixes that so writing to stderr will at least work.
Differential Revision: https://phabricator.services.mozilla.com/D47608
--HG--
extra : moz-landing-system : lando
The inline comment explains what is happening here. The issue is that
client.mk is setting MOZ_OBJDIR (and autoconf.mk is setting CC/CXX and
others) as part of `mach build`, which means that recursively invoking
`mach build` sees a different environment, and that triggers
reconfigure.
In some situations we can avoid this by recognizing that the
environment has changed and setting it back to what it was at the time
of `mach build` before client.mk adjusts it.
Differential Revision: https://phabricator.services.mozilla.com/D30425
--HG--
extra : moz-landing-system : lando
Since gradle doesn't run on sh.exe, it requires python path to run mach command.
But gradle doesn't have a way to detect python.exe.
When using MozillaBuild, it sets MOZILLABUILD environment value, so we can
detect python path in MozillaBuild using it if available.
Differential Revision: https://phabricator.services.mozilla.com/D20454
--HG--
extra : rebase_source : bba5ae6b8b53c408e8f80db3202458e177eecca4
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
We need to bump the Gradle Deps task, which fetches dependencies, to
include new test dependencies; and use freshly uploaded tooltool
archives (manually uploaded) containing the new test dependencies.
MozReview-Commit-ID: 8bNOVQPHlk6
--HG--
extra : rebase_source : 0c80117fb58e43f9c857027941f0a14f03b97f13
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
MozReview-Commit-ID: 4fCY504UgPu
--HG--
rename : mobile/android/app/base/lint.xml => mobile/android/app/lint.xml
rename : mobile/android/tests/background/junit4/resources/robolectric.properties => mobile/android/app/src/main/resources/robolectric.properties
extra : rebase_source : 689e879dd4ec4402d5e7f948fa5f8be256284a88
extra : intermediate-source : 746468f5d9798ff404a80cd957664e2b69a0e97c
extra : source : a7f63b3721cd3ba105990bbb37a87044383d26d9
extra : histedit_source : 6bdcfa36ddb45bbfd518c5459e4940e29a30f1c2%2C4bfef3b752a85174f1aa1f2226a286ac30bae25a
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
--HG--
rename : mobile/android/app/base/lint.xml => mobile/android/app/lint.xml
rename : mobile/android/tests/background/junit4/resources/robolectric.properties => mobile/android/app/src/main/resources/robolectric.properties
extra : commitid : 2aEbQRv0D7m
extra : rebase_source : c0f014e3fba7008967f8f9782125f940fcc89fe6
extra : amend_source : 46bfdfb116c026da490750a23a9c9188ab4cdf9a
extra : source : a7f63b3721cd3ba105990bbb37a87044383d26d9
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
--HG--
rename : mobile/android/app/base/lint.xml => mobile/android/app/lint.xml
rename : mobile/android/tests/background/junit4/resources/robolectric.properties => mobile/android/app/src/main/resources/robolectric.properties
extra : commitid : BSiXkLh5kSh
extra : rebase_source : ee178b04cd727e11a65f0550d88f1cd951cc5b7a
extra : amend_source : 45f49104a4687cf4cb71391c3f3ac2def8ef716a
This is the last Gradle project that isn't in the srcdir. Since base/
doesn't have the correct package prefix directory structure, we still
need to symlink, but we only need one link. This effectively
deprecates |mach gradle-install|.
This should improve the robustness of our Gradle configuration,
ensuring that we always have projects to import. Since
settings.gradle executes very early in the IDE import project
sequence: before Gradle project evaluation time, and thus before any
Gradle task is executed, we should always see a complete project. (It
was possible to see incomplete Gradle configurations if |mach
gradle-install| hadn't been run at just the right time.)
--HG--
extra : commitid : 4zK7U5PAypH
extra : rebase_source : 91f8534a89f0311b36bd39f502e2f7609a1d78b0
DONTBUILD NPOTB
The :omnijar project is for IntelliJ only; adding it neatly labels
folders we consider part of the omnijar in mobile/android. The JAR
produced is not used.
We add an evaluation-time dependency from :app to :omnijar so that we
can declare the set of omnijar folders exactly once. We'd prefer to
have the dependency in the other direction (to save evaluation time)
but there's an interface mismatch between the two Gradle model types.
See comments in the :omnijar project.
This is delicate.
--HG--
extra : commitid : 4TLicjMC7Bn
extra : rebase_source : 5dd4ab1e1fcdb296b46bc892b9e10414baadee61
I don't want to cut consumers of $OBJDIR/mobile/android/gradle over
yet, so this doesn't remove the existing 'thirdparty' project.
--HG--
rename : mobile/android/gradle/thirdparty/AndroidManifest.xml => mobile/android/thirdparty/AndroidManifest.xml
rename : mobile/android/gradle/thirdparty/build.gradle => mobile/android/thirdparty/build.gradle
extra : commitid : 8L8SU60bAig
extra : rebase_source : 0974b1e31821693b172f73119c4988c82a069a44
The sub-project definitions are still in the object directory (and
still installed by |mach gradle-install); over time, we'll migrate
them out.
The Gradle wrapper and {settings,build}.gradle in topsrcdir are
identical to those in mobile/android/gradle. I don't like the
duplication, but I also don't want the burden of keeping the two
configurations identical. We'll move away from the configuration
using mobile/android/gradle as quickly as we can.
--HG--
rename : mobile/android/gradle/build.gradle => build.gradle
rename : mobile/android/gradle/gradle/wrapper/gradle-wrapper.jar => gradle/wrapper/gradle-wrapper.jar
rename : mobile/android/gradle/gradle/wrapper/gradle-wrapper.properties => gradle/wrapper/gradle-wrapper.properties
rename : mobile/android/gradle/gradlew => gradlew
rename : mobile/android/gradle/settings.gradle => settings.gradle
extra : commitid : IkXCiKfkha1
extra : rebase_source : 4142fe37cd7e036d41fb122fe31cd232fcfdfc80
Nick Alexander
Andrew Halberstadt
Makoto Kato
maliu
Wes Kocher
Nigel Babu