It is natural to use the core library from source during development so that you don't have to build the AAR each time you make a change
However, this is a different style of module integration than using the AAR vs the typical module consumer integration
This difference exposes us to the risk that transitive dependency changes aren't tested thoroughly pre-release, which can lead to serious release failures such as #1114 - where the core sub-module had a transitive dependency that was pulled in via source integration but was missing in the module's dependency list causing crashes for module consumers
The default experience for developers on fork/clone here should still be for tests to use source integration I feel, but it should be conditional and possible to integrate via the typical AAR pathway if desired. Then in CI the AAR should be built first and the integration should be via the fresh AAR
Alternatively, the entire core / module split could be done away with via a gradle copy task that was executed as "the core build" during testing, and also pre-publish to npm such that the core source files lived alongside the modules and no AAR build step was required - e.g.:
https://github.com/ankidroid/Anki-Android/blob/1ffb3cca4db0a4e5a25633f9ac76cd51b56c561a/AnkiDroid/build.gradle#L275-L282
tasks.register('copyTestLibIntoAndroidTest', Copy) {
into new File(rootProject.rootDir, 'AnkiDroid/src/androidTest/java/com/ichi2/testutils')
from new File(rootProject.rootDir, 'testlib/src/main/java/com/ichi2/testutils')
into ('common') {
from 'common'
}
}
tasks.named('preBuild').configure { dependsOn('copyTestLibIntoAndroidTest') }
It is natural to use the core library from source during development so that you don't have to build the AAR each time you make a change
However, this is a different style of module integration than using the AAR vs the typical module consumer integration
This difference exposes us to the risk that transitive dependency changes aren't tested thoroughly pre-release, which can lead to serious release failures such as #1114 - where the core sub-module had a transitive dependency that was pulled in via source integration but was missing in the module's dependency list causing crashes for module consumers
The default experience for developers on fork/clone here should still be for tests to use source integration I feel, but it should be conditional and possible to integrate via the typical AAR pathway if desired. Then in CI the AAR should be built first and the integration should be via the fresh AAR
Alternatively, the entire core / module split could be done away with via a gradle copy task that was executed as "the core build" during testing, and also pre-publish to npm such that the core source files lived alongside the modules and no AAR build step was required - e.g.:
https://github.com/ankidroid/Anki-Android/blob/1ffb3cca4db0a4e5a25633f9ac76cd51b56c561a/AnkiDroid/build.gradle#L275-L282