Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a better way of managing Android dependencies for codegen #576

Open
HosseinYousefi opened this issue Aug 24, 2023 · 5 comments
Open

Comments

@HosseinYousefi
Copy link
Member

HosseinYousefi commented Aug 24, 2023

I think there is a case to be made to completely remove maven support from jnigen's main workflow. We might instead add some helper scripts like dart run jnigen:maven_init that create the intial pom.xml files in the directory.

_Originally posted by @HosseinYousefi in #742

@HosseinYousefi HosseinYousefi transferred this issue from dart-archive/jnigen Nov 17, 2023
parlough pushed a commit to parlough/native that referenced this issue Apr 8, 2024
@HosseinYousefi HosseinYousefi moved this to Backlog in JNIgen tracker Apr 11, 2024
@HosseinYousefi HosseinYousefi added this to the JNI / JNIgen 0.11.0 milestone May 15, 2024
@HosseinYousefi HosseinYousefi moved this from Backlog to Todo in JNIgen tracker May 15, 2024
@HosseinYousefi HosseinYousefi self-assigned this May 15, 2024
@HosseinYousefi
Copy link
Member Author

A package similar to native_toolchain_c, to "replace" writing gradle/maven. Users can add their dependencies to build.dart.

Pros:

@mosuem @dcharkes wdyt?

@mosuem
Copy link
Member

mosuem commented Jul 17, 2024

I know next to nothing about gradle and maven - so no thoughts from my side. 😉

@dcharkes
Copy link
Collaborator

that create the initial pom.xml files in the directory.

What is the output of this user-written hook/build.dart? Currently there's no way to have a "side-effect" (some file existing in your project afterwards).

Such "side-effects" would also only happen during the first Dart compilation (which is inside the Gradle build of an Android app in Flutter), so if you're side-effect generating a file that the Android native build should have picked up, it's too late already. Also, such side effects would happen multiple times in Flutter builds (multiple target architectures), and even more times in flutter run (dry runs).

If you want some file to appear in the project, then it should be a post-pub-get hook instead of a build hook?

Or maybe I've misunderstood what you're trying to achieve. Could you provide more details?

@HosseinYousefi
Copy link
Member Author

Or maybe I've misunderstood what you're trying to achieve. Could you provide more details?

Something similar to what we want to achieve for C. We could and can still add an externalNativeBuild to build.gradle to build and bundle some C code. In parallel to that, we could build and bundle some C code using build hooks. Both of these will be included.

So users can do something like:

addDependencies([
  'foo.bar',
  'baz.qux',
]);

And these libraries are also downloaded and bundled, alongside anything that already exists in build.gradle.

that create the initial pom.xml files in the directory.

The pom.xml file was the original idea behind this issue. Here, I'm suggesting a different way.

@HosseinYousefi
Copy link
Member Author

HosseinYousefi commented Jul 17, 2024

Notes from a discussion with @dcharkes

Managing Android dependencies for codegen

Current workflow

  1. Add the dependency to your plugin's build.gradle
  2. Create an example flutter app that has a main.dart
  3. [Currently] add the same dependency to the build.gradle of the example because somehow the transitive resolution of dependencies is buggy
  4. Add the location of the example app to jnigen.yaml and set add_gradle_deps to true
  5. cd example/ && flutter build apk so gradle resolves and caches the dependencies
  6. cd .. && dart run jnigen --config jnigen.yaml to finally generate the bindings

What are we solving here? The fact that the user doesn't have to specify the dependency in build.gradle AND download a .jar file and/or specify the same dependency again in jnigen.yaml. This can be error-prone due to for example, a version mismatch.

But this approach is extremely hacky. It includes having to build an example project, passsing the path to the example project in the config, and editing the build.gradle file of the example project!

A nicer workflow

  1. Add the dependency to pubspec.yaml
  2. Run dart pub get (which happens when saving the pubspec file in VSCode).
  3. dart run tool/jnigen.dart to generate the bindings.

How to achieve?

Codegen is in the development phase, so we don't want to build to get the dependencies. We need something like a "post-pub-get-hook" that happens after dart pub get. This can download dependencies that are required for codegen from their specification in pubspec.yaml. As a PoC, at first this can be a separate command like dart run jnigen:get.

The same dependencies are then used in the build hook to be bundled in, so the user won't have to specify them twice.

This also solves the hacky ways of accessing the gradle cache.

Concrete steps

For building and bundling we need #1350. Once this and the general jnigen:get workflow work, we can consider designing a "post-pub-get-hook" to simplify development. This gives the ability to call our tool/jnigen.dart directly in hook/post_pub.dart(?) so changes to the dependencies cause an auto-regen.

@HosseinYousefi HosseinYousefi removed this from the JNI / JNIgen 0.12.0 milestone Oct 1, 2024
@HosseinYousefi HosseinYousefi moved this from Todo to Backlog in JNIgen tracker Oct 1, 2024
@HosseinYousefi HosseinYousefi changed the title Remove Maven support in favor of helpers Provide a better way of managing Android dependencies for codegen Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Backlog
Development

No branches or pull requests

3 participants