Open Nava2 opened 1 year ago
👋 I'm one of the engineers working on frameworks at Cash.
We'd have to migrate our internal downstream services before we're able to do the migration to Guice 7. Will talk to the team about where to prioritise that. Given Guice 7 doesn't really have anything that isn't in Guice 6 at the moment, I'd lean towards doing the cutover later.
Using detekt would be great to check for imports!
I'm curious btw, why com.google.inject
instead of jakarta.inject
if they both work? I think I'd prefer to use the more generic one of the two where possible.
If we used Jakarta, it would force usage of 6.0+.. which seems fine... 🤦🏻 Admittedly, I'm biased as our downstream services are not on 6.0 yet and it would force our update - which we need to do.
I agree strongly with holding off on the cutover until later, but doing the initial migration to Jakarta seems good to get done.
I'd also lean towards jakarta.inject
instead of com.google.inject
since it looks like javax.inject
has been replaced by jakarta.inject
https://github.com/google/dagger/issues/2058#issuecomment-677925454
Wanted to make an issue for tracking migration to Guice 7.0.0.
@ThePumpingLemma migrated to using Guice 6.0.0 (#2846), however, there remains issues with projects wanting to use
misk-inject
with Guice 7+. The largest issue is that when a project tries to use Guice 7+, it can not inject classes that are labelled withjavax.inject.XXX
annotations. Guice 6+ happily accepts bothjakarta
andjavax
.Proposed path forwards
It seems like the path to migration would be twp steps:
javax.inject.XXX
withcom.google.inject.XXX
jakarta.inject
in their own projects, while consumingmisk-inject
@ 6.0.0com.google.inject.XXX
withjakarta.inject.XXX
Open question
detekt
. Could we enable forbidding imports to enforce only usingjakarta.inject.XXX
?P.S. I'm happy to do the find-and-replace 😄