This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
DONTBUILD ON A CLOSED TREE: Android-only and the build changes are cosmetic.
Very much a first cut, but I'd like to get some Fennec early adopters testing.
This adds:
* |mach artifact install| to fetch and install Fennec binaries;
* |mach artifact last| to print details about what was last installed;
* |mach artifact {print,clear}-caches|, for debugging.
This code is exposed as a new mozbuild.artifacts Python but it's not
particularly general. My intention was to get things out of the mach command
more than produce a general artifact fetching API. We can leave that bike
shed to Bug 1124378.
I've been testing this with --disable-compile-environment and it works well
locally, although there's no reason a knowledgeable developer couldn't use
this in conjunction with a fully-built tree. (I don't know when such a
situation would arise, but I know of no technical impediment.)
There are several parts to this ticket:
1) Produce javaaddons-1.0.jar, a standalone JAR defining a (versioned)
Java interface suitable for consumption by third-party Java addon
implementations.
2) Support the new V1 interface in the JavaAddonManager.
3) Add Robocop JavascriptTests testing the JavaScript message passing
interface to and from Java.
This patch can be read as "not in tests/" and "everything in tests/".
There are few things happening here:
* A purely mechanical move of test sources into org.mozilla.test.browser.junit3.
This is only to make it easy to specify the suite in Spoon. (But it has the
advantage of making it possible to move files around in IntelliJ, since the
symlink points to src instead of org/mozilla/gecko.)
* Specifying the suite (package name) ended up requiring changes to the
spoon-gradle-plugin anyway. Hence, I've included this custom
spoon-gradle-plugin version locally, while I work to upstream the changes.
* Some Gradle trickery to make |mach gradle runBrowserTests| execute Spoon with
the correct package name.
While it might seem like a good idea to disable all of the checks we don't
currently pass, Intellij uses the same lint configuration file as the
command-line invocation and so we'll be more likely to write in new errors by
disabling some checks.
DONTBUILD NPOTB
Local developers should only be building debug APKs. I intend
automation to only build release APKs, and automation will insert the
omnijar and native libraries into the release APK during packaging.
This change requires local developers to delete
$OBJDIR/mobile/android/gradle/app/src/main/{assets,jniLibs}.
The important change here is that we allow the Android-Gradle plugin
to be version 0.14.4 or version 1.0.0, which appears to work in
IntelliJ 14.0.2 and in Android Studio 1.0.2.
Testing feedback came from imjalpreet and garvank.
--HG--
extra : rebase_source : 2b93dd91603666f1c6a1d2fe0fa7721d5741bdda
This is a big patch, but it's essentially NPOTB. The part that is POTB
is ... removing Gradle integration from the build. I've implemented
|mach gradle-install| as a substitute for the build system stuff; it's
just so much easier to iterate on a mach command than a moz.build and
Makefile.in.
I'm landing this with self-review because this lessens the impact of the
Gradle integration on the build system and because I am the only person
who understands either the old or the new system.
You'll need to run |mach gradle-install| at top level to configure the
new Gradle integration. But |mach gradle ...| does the right thing
configuration steps too.
This patch rewrites most of the Gradle integration. The major changes
are:
* all .gradle files move into mobile/android/gradle;
* all the Gradle projects live in the object directory;
* mozconfig exposed to all build.gradle files;
* simplification of Android configuration between build.gradle files;
* support for user-specified version of build tools;
* first steps towards supporting builds from the source directory;
* bumps Gradle to 2.2.1;
* bumps the Android-Gradle plugin to 0.14.4.
This is seemingly a step backwards given that we'd prefer to ship the
.idea directory in the source directory. But in fact we get closer to
that; it's possible to run ./gradlew in the source directory and get a
reasonable build. We'll progress with this in time. The win right now
is that the projects are nested, which makes importing work better on
Linux machines.
Unfortunately IntelliJ 13 and 14 now have conflicting Android-Gradle
plugin version requirements, so we now only support IntelliJ 14.0.2 and
above.
--HG--
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/base/AndroidManifest.xml
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/branding/AndroidManifest.xml
rename : mobile/android/gradle/omnijar/gradle_AndroidManifest.xml => mobile/android/gradle/omnijar/AndroidManifest.xml
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/preprocessed_code/AndroidManifest.xml
rename : mobile/android/base/gradle_AndroidManifest.xml => mobile/android/gradle/preprocessed_resources/AndroidManifest.xml
rename : mobile/android/thirdparty/gradle_AndroidManifest.xml => mobile/android/gradle/thirdparty/AndroidManifest.xml
I went with gradle instead of gradlew because it's more likely to be
what users consider. And mach helpfully fixes up the uncommon typo.
This is a little hard-coded right now but I don't think it's likely
any other Gradle consumer will arise in the short term.
--HG--
extra : source : 67ce3d7591f944fa458758d97f443651f0e40dac
extra : amend_source : d10846e845deda5d368bdfdbb5b3d68706038992
extra : histedit_source : fb30750f389444a9619778d4c690d7de5e5fcbc1
