native
native copied to clipboard
package:android_jni package:java_jni repositories
https://github.com/mahesh-hegde/android_jni proof of concept using current PR dart-lang/jnigen#110
_Originally posted by @mahesh-hegde in https://github.com/dart-lang/native/issues/731
If we want to start making the generated bindings available (as very experimental) we need to solve some logistics questions.
Should package:android_jni and package:java_jni live in this repository? Or in separate ones.
Arguments for the same repository:
- Whenever we change the generated code, we would atomically change the generated bindings as well in the same commit.
- All tests of the standard library packages would be run on every jnigen commit.
Arguments for a separate repositories:
- We probably want to write a lot of tests and examples using the generated bindings, these commits would all show up in the same git history.
- Flexibility to not depend on the latest version of package:jnigen/package:jni.
- We could with some CI trickery probably run all the package:android_jni/package:java_jni tests with newly generated bindings with jnigen and a path dependency to the last version of jnigen/jni on the jnigen/jni repository.
package:java_jni and package:android_jni need to be different packages, because using the Android APIs on a desktop/CLI app that spawns a JVM itself, there are no Android APIs.
FYI @mit-mit
PR Reviewing: changes in jnigen cause really huge diffs if we have them in same repo. But in case of different repo maybe we can setup a bot or something.
Crosslink, this is a question about the repo for:
- https://github.com/dart-lang/native/issues/761
We probably want to do this after 1.0. I'll keep it in the backlog.