Consolidate megazord-related gradle logic into a shared helper. (#4187)
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.
This commit is contained in:
Ryan Kelly
GitHub
Родитель
65c88a630a
Коммит
28e4982cd2
|
|
@ -27,11 +27,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
|
||||
testOptions {
|
||||
unitTests {
|
||||
includeAndroidResources = true
|
||||
|
|
@ -52,43 +47,12 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
dependencies {
|
||||
// Part of the public API.
|
||||
api project(':sync15')
|
||||
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:4.2.1'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -99,22 +63,7 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
ext.configureUniFFIBindgen("../src/autofill.udl")
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -22,14 +22,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
|
||||
// This is required to support new AndroidX support libraries.
|
||||
// See mozilla-mobile/android-components#842
|
||||
compileOptions {
|
||||
|
|
@ -44,40 +36,9 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
dependencies {
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -86,23 +47,7 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
ext.configureUniFFIBindgen("../src/crashtest.udl")
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -22,14 +22,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
|
||||
// This is required to support new AndroidX support libraries.
|
||||
// See mozilla-mobile/android-components#842
|
||||
compileOptions {
|
||||
|
|
@ -44,40 +36,9 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
dependencies {
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -86,22 +47,7 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
ext.configureUniFFIBindgen("../src/fxa_client.udl")
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -26,14 +26,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
|
||||
}
|
||||
testOptions {
|
||||
unitTests {
|
||||
includeAndroidResources = true
|
||||
|
|
@ -54,23 +46,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
// Needs to happen before `dependencies` in order for the variables
|
||||
// exposed by the plugin to be available for this project.
|
||||
apply plugin: "org.mozilla.telemetry.glean-gradle-plugin"
|
||||
|
|
@ -79,24 +54,10 @@ dependencies {
|
|||
// Part of the public API.
|
||||
api project(':sync15')
|
||||
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
implementation "org.mozilla.components:service-glean:$android_components_version"
|
||||
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.13'
|
||||
testImplementation 'org.robolectric:robolectric:4.2.1'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -108,22 +69,7 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["generate${productFlavor}${buildType}Assets"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
ext.configureUniFFIBindgen("../src/logins.udl")
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -26,11 +26,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
|
||||
testOptions {
|
||||
unitTests {
|
||||
includeAndroidResources = true
|
||||
|
|
@ -51,30 +46,10 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
ext.gleanYamlFiles = ["${project.projectDir}/../metrics.yaml"]
|
||||
apply plugin: "org.mozilla.telemetry.glean-gradle-plugin"
|
||||
|
||||
dependencies {
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "androidx.annotation:annotation:$androidx_annotation_version"
|
||||
|
||||
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$kotlin_coroutines_version"
|
||||
|
|
@ -82,20 +57,6 @@ dependencies {
|
|||
implementation "org.mozilla.components:service-glean:$android_components_version"
|
||||
implementation "androidx.core:core-ktx:$androidx_core_version"
|
||||
|
||||
// Unlike standard Nimbus which builds a standalone package, this version depends
|
||||
// on `:full-megazord` for the underlying native library. The full-megazord needs
|
||||
// to be configured to include the corresponding Nimbus FFI functions.
|
||||
implementation project(":native-support")
|
||||
api project(":full-megazord")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation "androidx.test:core-ktx:$androidx_test_core_version"
|
||||
testImplementation "androidx.test.ext:junit-ktx:$androidx_test_junit_version"
|
||||
testImplementation "org.robolectric:robolectric:$roboelectric_core_version"
|
||||
|
|
@ -104,22 +65,7 @@ dependencies {
|
|||
testImplementation "org.mozilla.telemetry:glean-forUnitTests:$glean_version"
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
ext.configureUniFFIBindgen("../src/nimbus.udl")
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -29,9 +29,6 @@ android {
|
|||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
|
||||
main {
|
||||
proto {
|
||||
srcDir '../src'
|
||||
|
|
@ -59,22 +56,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
protobuf {
|
||||
protoc {
|
||||
// This is a hack for Apple M1 since protobuf does not compile for M1s yet
|
||||
|
|
@ -102,25 +83,12 @@ dependencies {
|
|||
// Part of the public API.
|
||||
api project(':sync15')
|
||||
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
implementation "org.mozilla.components:service-glean:$android_components_version"
|
||||
|
||||
implementation 'com.google.protobuf:protobuf-javalite:3.11.4'
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:4.2.1'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -132,22 +100,6 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -24,12 +24,6 @@ android {
|
|||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
|
||||
main {
|
||||
proto {
|
||||
srcDir '../src'
|
||||
|
|
@ -51,23 +45,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
protobuf {
|
||||
protoc {
|
||||
// This is a hack for Apple M1 since protobuf does not compile for M1s yet
|
||||
|
|
@ -90,23 +67,10 @@ protobuf {
|
|||
}
|
||||
|
||||
dependencies {
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
implementation 'com.google.protobuf:protobuf-javalite:3.11.4'
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -115,22 +79,6 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -22,14 +22,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
|
||||
// This is required to support new AndroidX support libraries.
|
||||
// See mozilla-mobile/android-components#842
|
||||
compileOptions {
|
||||
|
|
@ -44,40 +36,9 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
dependencies {
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -86,22 +47,6 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -24,9 +24,6 @@ android {
|
|||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
|
||||
main {
|
||||
proto {
|
||||
srcDir '../src'
|
||||
|
|
@ -48,22 +45,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
protobuf {
|
||||
protoc {
|
||||
// This is a hack for Apple M1 since protobuf does not compile for M1s yet
|
||||
|
|
@ -89,23 +70,10 @@ dependencies {
|
|||
// Part of the public API.
|
||||
api project(':sync15')
|
||||
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
implementation 'com.google.protobuf:protobuf-javalite:3.11.4'
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -114,22 +82,6 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -22,11 +22,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
|
||||
// This is required to support new AndroidX support libraries.
|
||||
// See mozilla-mobile/android-components#842
|
||||
compileOptions {
|
||||
|
|
@ -44,43 +39,12 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
|
||||
dependencies {
|
||||
// Part of the public API.
|
||||
api project(':sync15')
|
||||
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -89,22 +53,7 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
ext.configureUniFFIBindgen("../src/tabs.udl")
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -24,14 +24,7 @@ android {
|
|||
}
|
||||
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
|
||||
main {
|
||||
main {
|
||||
proto {
|
||||
srcDir '../src'
|
||||
}
|
||||
|
|
@ -52,22 +45,6 @@ android {
|
|||
}
|
||||
}
|
||||
|
||||
configurations {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
jnaForTest
|
||||
}
|
||||
protobuf {
|
||||
protoc {
|
||||
// This is a hack for Apple M1 since protobuf does not compile for M1s yet
|
||||
|
|
@ -91,23 +68,10 @@ protobuf {
|
|||
dependencies {
|
||||
api "org.mozilla.components:concept-fetch:$android_components_version"
|
||||
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
|
||||
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
|
||||
|
||||
implementation 'com.google.protobuf:protobuf-javalite:3.11.4'
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
testImplementation 'junit:junit:4.12'
|
||||
testImplementation 'org.robolectric:robolectric:3.8'
|
||||
testImplementation 'org.mockito:mockito-core:2.21.0'
|
||||
|
|
@ -116,22 +80,6 @@ dependencies {
|
|||
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
|
||||
}
|
||||
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
// The `cargoBuild` task isn't available until after evaluation.
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["merge${productFlavor}${buildType}JniLibFolders"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
|
||||
apply from: "$rootDir/publish.gradle"
|
||||
|
||||
ext.dependsOnTheMegazord()
|
||||
ext.configurePublish()
|
||||
|
|
|
|||
|
|
@ -224,3 +224,67 @@ ext.configureUniFFIBindgen = { udlFilePath ->
|
|||
variant.registerJavaGeneratingTask(t.get(), new File(buildDir, uniffiGeneratedPath))
|
||||
}
|
||||
}
|
||||
|
||||
// A convenience function for configuring a project to depend on the megazord
|
||||
// for native code. It sets up the correct set of dependencies for publishing
|
||||
// a package whose Rust code is included in the megazord, and for running its
|
||||
// tests using a local build.
|
||||
ext.dependsOnTheMegazord = {
|
||||
// There's an interaction between Gradle's resolution of dependencies with different types
|
||||
// (@jar, @aar) for `implementation` and `testImplementation` and with Android Studio's built-in
|
||||
// JUnit test runner. The runtime classpath in the built-in JUnit test runner gets the
|
||||
// dependency from the `implementation`, which is type @aar, and therefore the JNA dependency
|
||||
// doesn't provide the JNI dispatch libraries in the correct Java resource directories. I think
|
||||
// what's happening is that @aar type in `implementation` resolves to the @jar type in
|
||||
// `testImplementation`, and that it wins the dependency resolution battle.
|
||||
//
|
||||
// A workaround is to add a new configuration which depends on the @jar type and to reference
|
||||
// the underlying JAR file directly in `testImplementation`. This JAR file doesn't resolve to
|
||||
// the @aar type in `implementation`. This works when invoked via `gradle`, but also sets the
|
||||
// correct runtime classpath when invoked with Android Studio's built-in JUnit test runner.
|
||||
// Success!
|
||||
configurations {
|
||||
jnaForTest
|
||||
}
|
||||
// Add the full-megazord's build directory to our resource path so that
|
||||
// we can actually find it during tests. (Unfortunately, each project
|
||||
// has their own build dir)
|
||||
android {
|
||||
sourceSets {
|
||||
test.resources.srcDirs += "$buildDir/rustJniLibs/desktop"
|
||||
test.resources.srcDirs += "${project(':full-megazord').buildDir}/rustJniLibs/desktop"
|
||||
}
|
||||
}
|
||||
// Depend on the megazord and its support library, as well as the
|
||||
// above-mentione JNA stuff for testing.
|
||||
dependencies {
|
||||
api project(":full-megazord")
|
||||
implementation project(":native-support")
|
||||
jnaForTest "net.java.dev.jna:jna:$jna_version@jar"
|
||||
implementation "net.java.dev.jna:jna:$jna_version@aar"
|
||||
// For reasons unknown, resolving the jnaForTest configuration directly
|
||||
// trips a nasty issue with the Android-Gradle plugin 3.2.1, like `Cannot
|
||||
// change attributes of configuration ':PROJECT:kapt' after it has been
|
||||
// resolved`. I think that the configuration is being made a
|
||||
// super-configuration of the testImplementation and then the `.files` is
|
||||
// causing it to be resolved. Cloning first dissociates the configuration,
|
||||
// avoiding other configurations from being resolved. Tricky!
|
||||
testImplementation files(configurations.jnaForTest.copyRecursive().files)
|
||||
}
|
||||
// For running local tests, depend on a local `cargo build` of the megazord.
|
||||
// Unfortunately the `cargoBuild` task isn't available until after evaluation.
|
||||
evaluationDependsOn(":full-megazord")
|
||||
afterEvaluate {
|
||||
android.libraryVariants.all { variant ->
|
||||
def productFlavor = ""
|
||||
variant.productFlavors.each {
|
||||
productFlavor += "${it.name.capitalize()}"
|
||||
}
|
||||
def buildType = "${variant.buildType.name.capitalize()}"
|
||||
tasks["generate${productFlavor}${buildType}Assets"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
|
||||
// For unit tests.
|
||||
tasks["process${productFlavor}${buildType}UnitTestJavaRes"].dependsOn(project(':full-megazord').tasks["cargoBuild"])
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче