You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.:
tasks.register('copyTestLibIntoAndroidTest', Copy) {
into newFile(rootProject.rootDir, 'AnkiDroid/src/androidTest/java/com/ichi2/testutils')
from newFile(rootProject.rootDir, 'testlib/src/main/java/com/ichi2/testutils')
into ('common') {
from 'common'
}
}
tasks.named('preBuild').configure { dependsOn('copyTestLibIntoAndroidTest') }
The text was updated successfully, but these errors were encountered:
Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?
This issue will be closed in 15 days if no further activity occurs.
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
The text was updated successfully, but these errors were encountered: