Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
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
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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
hiltandhilt-android-componentsor something.Not entirely. But it would address the majority of our existing bindings.