Hilt is not compatible with pure Java Gradle modules
See original GitHub issueOur project has a number existing Java Gradle modules which expose Dagger modules. We cannot migrate these to use Hilt because the hilt-android
artifact is an AAR, which is incompatible.
Could some of the Android-agnostic annotations and interfaces be extracted to a separate hilt
jar artifact? (at least @InstallIn
, @AliasOf
, and the standard component interfaces)
I imagine that these are all bundled together be certain everything is on the classpath of generated code, but feel a workable subset could be extracted without too much headache?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:35
- Comments:11 (2 by maintainers)
Top Results From Across the Web
Hilt in non-android module clean architecture setup
The Domain module is java-only. I know it's possible to support hilt in non-android modules by adding: Domain build.gradle
Read more >Gradle Build Setup - Dagger
The Hilt Gradle plugin runs a bytecode transformation to make the APIs easier to use. The plugin was created for a better developer...
Read more >Hilt is stable! Easier dependency injection on Android - Medium
Hilt, Jetpack's recommended dependency injection (DI) solution for Android apps, is already stable! That means Hilt is fully ready to be used in...
Read more >Dagger Hilt in Android with Example - GeeksforGeeks
In order to use Dagger Hilt, we need to add the dependencies for it. First, we will add the classpath to our project-level...
Read more >Hilt in multi-module apps - Android Developers
Hilt code generation needs access to all the Gradle modules that use Hilt. The Gradle module that compiles your Application class needs to ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
That is probably the path we will follow for now.
My 2 cents is that since Hilt bills itself as a DI solution for Android, a Java-compatible base artifact would make sense for a “Java Gradle module in an Android project” use case. And since the component interfaces are only logically tied to Android (they don’t require Android classes), they could be included in a jar artifact instead. And if you really want separation, it could be
hilt
andhilt-android-components
or something.Not entirely. But it would address the majority of our existing bindings.