jakarta.inject support #1383

cogman · 2020-08-20T17:02:49Z

Jakarta is coming to cause headaches for all :)

It would be nice if Guice could support processing Jakarta inject annotations as well as javax inject annotations. That would prevent us from potentially having to write a cross injection system constructor like

@Inject
@jakarta.inject.Inject

Fortunately, they don't share a package and it looks like jakarta pretty much only changed the package name.

tandr · 2021-03-09T17:51:10Z

That's not a small undertaking - whole library sprinkled with java.inject namespace. Thinking about it - would an acceptable solution to have 2 libraries - guice-javax and guice-jakarta , and make them coexists somehow? (thinking out loud)

GedMarc · 2021-03-10T08:02:18Z

You can use the guiced-ee artifact for jakarta namespacing across the board

https://mvnrepository.com/artifact/com.guicedee.services/guice

kashike · 2021-05-24T22:10:24Z

Are there any plans to look into support for this?

d135-1r43 · 2021-06-01T08:03:13Z

I would be willing to contribute, maybe even with a small team.

onacit · 2022-02-09T09:20:32Z

@GedMarc Check this out, yo.

Azimuts · 2022-10-14T10:53:49Z

Guice's greatest virtue is its agility and that it is a DI library by itself with no frills added. Other DI and CDI solutions are fullstack If you want to use more modern application servers ( or other solutiones....) , on many occasions are forced to do a full stack migration. In itself a migration to , for example, toSpring, Micronaut, Quarkus is a full stack migration generating complicated dependencies that can condition the evolution of the applications.....

Indirectly, not supporting this small functionality is forcing developers to do full stack migrations and it's not easy to get out of there! Reconsider!

trintaaho · 2022-12-19T15:27:25Z

We need this.

csisy · 2023-03-17T10:09:54Z

Bump on this, still not resolved. Is there any workaround?

xvik · 2023-04-13T07:17:06Z

I did an automatic repackage of guice 5.1.0 (with tomcat migration tool) and published it yesterday into maven central (as rc.1 for now). Repackaged version use jakarta.inject, jakarta.servlet and jakarta.persistence.

Conversion performed on source jars (loaded from maven central) which are compiled then, so sources and javadoc are aligned in maven central publication. Pom and manifest files were manually rebuild (to replace dependencies and fix OSGI declarations). Struts2 and spring modules are not included (I doubt someone needs it).

Those who interesterested, please help me test it.

About 3rd party libraries: there would, of course, be problems with 3rd party libraies using javax.inject annotations: migrated guice would not see these annotations causing errors (e.g. not found constructor because of wrong annotation). In my libs I simply replaced all javax.inject.Inject annotations with gucie native annotations (so it could work with both javax and jakarta guice versions).

sameb · 2023-04-21T02:44:13Z

FYI all, I'm going to take some time early next week to fix this for core Guice.

I am still against outright forking the servlet extension into the jakarta namespace though, and will gladly welcome (and encourage) any community members that want to fork the servlet extension, fix its warts, and become the "official owners" of it.

sameb · 2023-04-25T14:13:38Z

Hi folks -- I have some changes prepared to support this for core Guice. However, the Dagger folks mentioned that they were informed of some issues related to supporting both javax.inject & jakarta.inject at the same time -- see google/dagger#2058 (comment). The TL;DR as best I can make out is:

javax.inject (from the javax.inject:javax.inject:1 maven coordinates) is old and doesn't have a "Automatic Module Name"
Jakarta folks re-published the javax inject APIs with a module name under jakarta.inject:jakarta.inject-api:1.0.5, but then went ahead and changed the packages to jakarta.inject but kept the jakarta coordinates and just incremented the version, to: jakarta.inject:jakarta.inject-api:2.0.1.
As a result, folks wanting JPMS-compatibility cannot use the original javax.inject:javax.inject:1 artifact (because it has no module name), and cannot use the jakarta.inject:jakarta.inject-api:1.0.5 and jakarta.inject:jakarta.inject-api:2.0.1 at the same time, because they're the same thing artifact (just with different versions). This means that folks wanting JPMS compatibility cannot reference both javax.inject and jakarta.inject at the same time.

How much of an issue is this for folks? My plan is basically to keep the javax.inject:javax.inject:1 dependency, introduce a new jakarta.inject:jakarta.inject-api:2.0.1 dependency, and have Guice depend on both the javax.inject namespace & the jakarta.inject namespace. But IIUC, that may break strict JPMS compatibility.

I'm open to ideas from folks more familiar with Maven about how to handle this.

(@mcculls FYI)

norrisjeremy · 2023-04-25T14:29:11Z

Why attempt to support both namespaces simultaneously, as opposed to just declaring Guice version X.Y.Z only supports the jakarta.inject namespace only?
Are folks wanting to intermix usage of both namespaces simultaneously?

sameb · 2023-04-25T14:39:28Z

@norrisjeremy -- For one, Google has quite literally millions of files referencing javax.inject. It isn't feasible to just up and say "switch'm all to another package". I wouldn't want to demand that from any other users either. Even if a migration were to happen, it would need to be incremental -- we can't just say "switch your entire codebase in order to use the new version".

One possibility here is to introduce a separate published artifact with a -jpms-compat suffix, and that artifact could potentially shade the javax.inject references. A naive shade would produce some awkward APIs, where Binder (for example) would have toProvider(Class<? extends shaded.javax.inject.Provider>)-like APIs. (The toProvider methods in Binder are also a problem in general for supporting jakarta.inject, so maybe there's another solution that could deal with those too.)

martin-g · 2023-04-25T15:06:42Z

On Tue, 25 Apr 2023 at 17:39, Sam Berlin ***@***.***> wrote: @norrisjeremy <https://github.com/norrisjeremy> -- For one, Google has quite literally millions of files referencing javax.inject. It isn't feasible to just up and say "switch'm all to another package". I wouldn't want to demand that from any other users either. Even if a migration were to happen, it would need to be incremental -- we can't just say "switch your entire codebase in order to use the new version".

Old apps can still use the current/old version of Guice. When an app is ready to switch to Jakarta it will bump to the new version of Guice that is based on Jakarta-inject 2.0.1 I guess you don’t want to maintain two major versions of Guice. But supporting both Javax and Jakarta simultaneously would be more work in my opinion.

…

One possibility here is to introduce a separate published artifact with a -jpms-compat suffix, and that artifact could potentially shade the javax.inject references. A naive shade would produce some awkward APIs, where Binder (for example) would have toProvider(Class<? extends shaded.javax.inject.Provider) API. (The toProvider methods in Binder are also a problem in general for supporting jakarta.inject, so maybe there's another solution that could deal with those too.) — Reply to this email directly, view it on GitHub <#1383 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABYUQWSTSWXKEGYKE6O4YTXC7O23ANCNFSM4QGL6RWQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

sameb · 2023-04-25T15:09:24Z

If I were able to cajole folks into a new release of javax.inject (at the javax.inject maven coordinates) that included a module name, etc.. would that make these problems go away?

cdietrich · 2023-05-05T08:16:15Z

i see this regression in 7 @sameb : #1729

sameb · 2023-05-05T19:50:26Z

Thanks for giving it a spin, @cdietrich, and glad to hear the regression was just a mistaken javax import.

All: I posted release notes & made a proper announcement post @ #1732. Please follow up there with your success or failure stories in adopting Guice 6.0 or 7.0. Thank you!

mkurz · 2023-05-08T20:27:41Z

6.0.0-rc2 works with the Play Framework and we do have quite some testing going on. I didn't change anything besides bumping the guice version (keep using javax.inject):

7.0.0-rc1 works as well also, switched everything to the jakarta namespace: playframework/playframework#11792
On GitHub the build fails, but this is because other (Play) dependencies didn't switch to Jakarta yet. Therefore I build those dependencies on my machine which also made all the tests pass locally 👍

hgschmie · 2023-05-08T20:35:20Z

We will be shipping support for both javax.inject (guice 5.x-6.x) and jakarta.inject (guice 7.x) in the next release of https://github.com/jdbi/jdbi. Testing looks good; ideally we could use the releases as base lines; everything works so far with the release candidates.

ben-manes · 2023-05-08T21:01:05Z

RestEasy dropped support for Guice when they migrated to Jakarta. That used to be the more popular JAX-RS framework to use with Guice since Jersey 2 had buggy integration due lifecycle clashes with HK2. I'm hoping they'll restore this module (RESTEASY-3329).

GedMarc · 2023-05-09T00:21:09Z

@ben-manes they also dropped any future support for any modules in their entirety - by separating out the spi's,

Rest Easy is not compatible with modular development, Guice is a modular DI.
I would not hold my breath for that, intentional move by rest easy. Also, it's not future compliant in any way, zero loss. A rest handler and api isn't required in any JDK 9 and up In any shape or form

sameb · 2023-05-09T00:36:07Z

Thanks all, this is great to hear that things are working in your environments. If it's possible to continue the discussion on the release announcement @ #1732, it's a little easier to keep track of the one discussion post instead of comments inside a closed issue.

Guice 6.x release is adding support for jakarta.inject, see this issue for more details: [1]. Guice release 7.0.0 will remove support for javax.inject annotation and only support jakarta.inject. Also add new dependency to jakarta.inject library. [1] google/guice#1383 Release-Notes: Update guice version to 6.0.0 Change-Id: I0eb5320289bde532ac57bdd376802b37c1cee47f

…f spring boot 3.x upgrade While upgrading the spring boot to 3.0.13 and spring cloud 2022.0.5, encountered the below error: ``` Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'javax.inject.Provider<com.netflix.spectator.api.Registry>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {} at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1824) at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1383) at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1337) at app//org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:910) at app//org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:788) ... 175 more ``` The root cause is use of `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in kork-eureka, kork-plugins and kork-web modules. google/guice#1463 google/guice#1383 https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject

…grade wiremock as part of spring boot 3.x upgrade While upgrading the spring boot to 3.0.13 and spring cloud 2022.0.5, encountered the below errors: ``` Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'javax.inject.Provider<com.netflix.spectator.api.Registry>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {} at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1824) at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1383) at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1337) at app//org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:910) at app//org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:788) ... 175 more ``` The root cause is use of `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in kork-eureka, kork-plugins and kork-web modules. google/guice#1463 google/guice#1383 https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject ``` javax/servlet/DispatcherType java.lang.NoClassDefFoundError: javax/servlet/DispatcherType at com.github.tomakehurst.wiremock.jetty9.JettyHttpServerFactory.buildHttpServer(JettyHttpServerFactory.java:31) at com.github.tomakehurst.wiremock.WireMockServer.<init>(WireMockServer.java:74) at com.netflix.spinnaker.kork.plugins.sdk.httpclient.Ok3HttpClientIntegrationTest$Fixture.<init>(Ok3HttpClientIntegrationTest.kt:78) at com.netflix.spinnaker.kork.plugins.sdk.httpclient.Ok3HttpClientIntegrationTest$test$1$1.invoke(Ok3HttpClientIntegrationTest.kt:40) at com.netflix.spinnaker.kork.plugins.sdk.httpclient.Ok3HttpClientIntegrationTest$test$1$1.invoke(Ok3HttpClientIntegrationTest.kt:40) at dev.minutest.TestContextBuilder$fixture$1.invoke(ContextBuilder.kt:48) ``` In order to fix this issue, upgrading wiremock dependency to 3.0.4 and updating its coordinates. Wiremock [3.0.0](https://github.com/wiremock/wiremock/releases/tag/3.0.0) onwards 2 major breaking changes are introduced: 1. support for Java 17, dropping Java 8 support 2. Change the Maven repository groupID to org.wiremock https://github.com/wiremock/wiremock/releases?page=3

… cloud from 2021.0.x to 2022.0.x Upgrading spring boot 2.7.18 to 3.0.13 and spring cloud 2021.0.8 to 2022.0.5. Spring cloud release 2022.0.x is compatible with spring boot 3.0.x. https://github.com/spring-cloud/spring-cloud-release/wiki/Supported-Versions#supported-releases ====================================================== refactor(dependency): replace javax with jakarta, javax.inject with jakarta.inject, rxjava with rxjava3 and add resilience4j-vavr during upgrade of spring boot 3.0.x Spring Boot 3.0 has migrated from Java EE to Jakarta EE APIs for all dependencies. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes#third-party-library-upgrades So, replacing the imports with `javax` to `jakarta`. Spring boot 3.x deprecated and removed rxjava, and rxjava3 has been added. So, update the dependency. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#rxjava `io.vavr` dependency has been removed from resilience4j:2.0.2. https://github.com/resilience4j/resilience4j/releases/tag/v2.0.0 Resilience4j comes as transitive dependency of spring-cloud-dependencies. https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-dependencies/2022.0.5 So, adding explicit dependency of `resilience4j-vavr` `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in igor-web module. google/guice#1463 google/guice#1383 https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject

… cloud from 2021.0.x to 2022.0.x Upgrading spring boot 2.7.18 to 3.0.13 and spring cloud 2021.0.8 to 2022.0.5. Spring cloud release 2022.0.x is compatible with spring boot 3.0.x. https://github.com/spring-cloud/spring-cloud-release/wiki/Supported-Versions#supported-releases `WebMvcConfigurerAdapter` class has been deprecated in Springframework 5.0 and subsequently removed from Springframework 6.0. So, replacing it with `WebMvcConfigurer` interface for direct implementation. https://docs.spring.io/spring-framework/docs/5.0.0.RELEASE/javadoc-api/org/springframework/web/servlet/config/annotation/WebMvcConfigurerAdapter.html =============================================================================================== refactor(dependency): replace javax with jakarta and javax.inject with jakarta.inject during upgrade of spring boot 3.0.x Spring Boot 3.0 has migrated from Java EE to Jakarta EE APIs for all dependencies. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes#third-party-library-upgrades So, replacing the imports with `javax` to `jakarta`. `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in igor-web module. google/guice#1463 google/guice#1383 https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject =============================================================================================== refactor(jedis): migrate jedis from 3.x to 4.x during upgrade of spring boot 3.0.x Spring boot upgrade from 2.7.18 to 3.0.13, upgrades `redis.clients:jedis` from 3.8.0 to 4.3.2. So, migrating jedis from 3.x to 4.x by following the migration [document](https://github.com/redis/jedis/blob/master/docs/3to4.md) And for further changelogs, please refer [here](https://github.com/redis/jedis/releases/tag/v4.0.0) =============================================================================================== refactor(dependency): migrate rxjava to rxjava3 during upgrade of spring boot 3.0.x Spring boot 3.x deprecated and removed rxjava, and rxjava3 has been added. So, update the dependency. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#rxjava And refactored the code to accomodate changes required by rxjava2 and rxjava3 following the changelogs. https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0 https://github.com/ReactiveX/RxJava/wiki/What%27s-different-in-3.0 =============================================================================================== refactor(dependency): add explicit resilience4j-vavr dependency with spring boot upgrade to 3.x `io.vavr` dependency has been removed from resilience4j:2.0.2. https://github.com/resilience4j/resilience4j/releases/tag/v2.0.0 Resilience4j comes as transitive dependency of spring-cloud-dependencies. https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-dependencies/2022.0.5 So, adding explicit dependency of `resilience4j-vavr` As part of removing vavr dependency, resilience4j has made change that returns a Set instead of Seq when retryRegistry.getAllRetries() is called. Link: https://github.com/resilience4j/resilience4j/pull/1121/files#diff-f58a549005afee4cef1bdce1c1a5571f40fcede02013722f6bd05d221bde56eeR153 resilience4j/resilience4j#1537

…grade wiremock as part of spring boot 3.x upgrade While upgrading the spring boot to 3.0.13 and spring cloud 2022.0.5, encountered the below errors: ``` Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'javax.inject.Provider<com.netflix.spectator.api.Registry>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {} at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1824) at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1383) at app//org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1337) at app//org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:910) at app//org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:788) ... 175 more ``` The root cause is use of `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in kork-eureka, kork-plugins and kork-web modules. google/guice#1463 google/guice#1383 https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject ``` javax/servlet/DispatcherType java.lang.NoClassDefFoundError: javax/servlet/DispatcherType at com.github.tomakehurst.wiremock.jetty9.JettyHttpServerFactory.buildHttpServer(JettyHttpServerFactory.java:31) at com.github.tomakehurst.wiremock.WireMockServer.<init>(WireMockServer.java:74) at com.netflix.spinnaker.kork.plugins.sdk.httpclient.Ok3HttpClientIntegrationTest$Fixture.<init>(Ok3HttpClientIntegrationTest.kt:78) at com.netflix.spinnaker.kork.plugins.sdk.httpclient.Ok3HttpClientIntegrationTest$test$1$1.invoke(Ok3HttpClientIntegrationTest.kt:40) at com.netflix.spinnaker.kork.plugins.sdk.httpclient.Ok3HttpClientIntegrationTest$test$1$1.invoke(Ok3HttpClientIntegrationTest.kt:40) at dev.minutest.TestContextBuilder$fixture$1.invoke(ContextBuilder.kt:48) ``` In order to fix this issue, upgrading wiremock dependency to 3.0.4 and updating its coordinates. Wiremock [3.0.0](https://github.com/wiremock/wiremock/releases/tag/3.0.0) onwards 2 major breaking changes are introduced: 1. support for Java 17, dropping Java 8 support 2. Change the Maven repository groupID to org.wiremock https://github.com/wiremock/wiremock/releases?page=3

… cloud from 2021.0.x to 2022.0.x Upgrading spring boot 2.7.18 to 3.0.13 and spring cloud 2021.0.8 to 2022.0.5. Spring cloud release 2022.0.x is compatible with spring boot 3.0.x. https://github.com/spring-cloud/spring-cloud-release/wiki/Supported-Versions#supported-releases =============================================================================================== refactor(dependency): replace javax with jakarta and javax.inject with jakarta.inject during upgrade of spring boot 3.0.x Spring Boot 3.0 has migrated from Java EE to Jakarta EE APIs for all dependencies. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Release-Notes#third-party-library-upgrades So, replacing the imports with `javax` to `jakarta`. `javax.inject` that has been moved from present coordinate to `jakarta.inject`. So, updating the coordinates in igor-web module. google/guice#1463 google/guice#1383 https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxinjectmigrationtojakartainject =============================================================================================== refactor(dependency): migrate rxjava to rxjava3 during upgrade of spring boot 3.0.x Spring boot 3.x deprecated and removed rxjava, and rxjava3 has been added. So, update the dependency. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#rxjava And refactored the code to accomodate changes required by rxjava2 and rxjava3 following the changelogs. https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0 https://github.com/ReactiveX/RxJava/wiki/What%27s-different-in-3.0 =============================================================================================== refactor(dependency): upgrade wiremock as part of spring boot 3.x and spring cloud 2022.0.x upgrade Upgrading wiremock dependency to 3.0.4 and updating its coordinates. Wiremock [3.0.0](https://github.com/wiremock/wiremock/releases/tag/3.0.0) onwards 2 major breaking changes are introduced: 1. support for Java 17, dropping Java 8 support 2. Change the Maven repository groupID to org.wiremock https://github.com/wiremock/wiremock/releases?page=3 3. Change Artifact IDs of wiremock-jre8 and wiremock-jre8-standalone to wiremock and wiremock-standalone =============================================================================================== refactor(dependency): upgrade greenmail as part of spring boot 3.x and spring cloud 2022.0.x upgrade Greenmail dependency is used for email notifications in echo. Greenmail 1.5.14 is based on javax.mail package. With spring boot 3.x upgrade javax.mail package has been replaced with jakarta.mail, so, upgrading the greenmail to 2.0.1 which is based on jakarta.mail package. https://github.com/greenmail-mail-test/greenmail/releases/tag/release-2.0.1

cogman mentioned this issue Dec 12, 2020

Replace javax.inject with jakarta.inject #1463

Closed

oswaldquek mentioned this issue Jan 4, 2021

Bump org.eclipse.persistence.jpa from 2.7.7 to 3.0.0 alphagov/pay-adminusers#910

Closed

hejcz mentioned this issue Feb 19, 2021

Support for jakarta annotations #1490

Closed

Ladicek mentioned this issue Mar 24, 2021

Add qualifier to DriversSeat in TCK jakartaee/inject-tck#15

Closed

alexbishop1 mentioned this issue Sep 29, 2021

Bump org.eclipse.persistence.jpa from 2.7.7 to 3.0.2 alphagov/pay-products#701

Closed

oswaldquek mentioned this issue Sep 29, 2021

Upgrade hibernate version to support JPA 3.0 #1541

Closed

basil mentioned this issue Dec 19, 2021

Jakarta EE 9 transition jenkinsci/jenkins#6085

Closed

pierre mentioned this issue Apr 21, 2022

build(deps): bump jakarta.servlet-api from 4.0.4 to 5.0.0 killbill/killbill-oss-parent#374

Closed

nikosmoum mentioned this issue Jun 17, 2022

Support for JPA 3.0 (jakarta.persistence) #1637

Closed

froque mentioned this issue Jul 5, 2022

Move to jakarta packages premium-minds/billy#157

Open

kdombeck mentioned this issue Jul 21, 2022

Upgrade Jetty to version 10.x. logzio/guice-jersey#34

Merged

agentgt mentioned this issue Sep 16, 2022

Jakarta inject jooby-project/jooby#2631

Merged

jklingsporn mentioned this issue Dec 9, 2022

javax to jakarta jklingsporn/vertx-jooq#216

Open

mkurz mentioned this issue May 8, 2023

Guice 7 + switch to Jakarta Dependency Injection playframework/playframework#11792

Merged

This was referenced Jun 9, 2023

jakarta.inject support ben-manes/caffeine#1009

Closed

Migrate from javax package to jakarta logzio/guice-jersey#36

Merged

andriygg mentioned this issue Jan 31, 2024

major(deps): Upgrade to Guice v7 pleo-io/prop#239

Merged

This was referenced May 21, 2024

Bump javax.inject:javax.inject from 1 to 1-redhat-2 [dont merge] replay-framework/replay#335

Closed

Replace javax.inject with jakarta.inject replay-framework/replay#386

Closed

j-sandy mentioned this issue Dec 12, 2024

chore(dependency): replace javax.inject with jakarta.inject and javax with jakarta spinnaker/kork#1217

Closed

j-sandy mentioned this issue Dec 19, 2024

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring cloud from 2021.0.x to 2022.0.x spinnaker/kork#1216

Draft

j-sandy mentioned this issue Jan 9, 2025

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring cloud from 2021.0.x to 2022.0.x spinnaker/igor#1299

Draft

j-sandy mentioned this issue Feb 17, 2025

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring cloud from 2021.0.x to 2022.0.x spinnaker/clouddriver#6348

Draft

j-sandy mentioned this issue Mar 4, 2025

chore(dependency): upgrade spring boot from 2.7.x to 3.0.x and spring cloud from 2021.0.x to 2022.0.x spinnaker/echo#1484

Draft

guluo2016 mentioned this issue Mar 8, 2025

AMBARI-26309: Ambari server takes up about an hour to start apache/ambari#3950

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

jakarta.inject support #1383

jakarta.inject support #1383

cogman commented Aug 20, 2020

tandr commented Mar 9, 2021 •

edited

Loading

GedMarc commented Mar 10, 2021

kashike commented May 24, 2021

d135-1r43 commented Jun 1, 2021

onacit commented Feb 9, 2022

Azimuts commented Oct 14, 2022 •

edited

Loading

trintaaho commented Dec 19, 2022

csisy commented Mar 17, 2023

xvik commented Apr 13, 2023

sameb commented Apr 21, 2023

sameb commented Apr 25, 2023 •

edited

Loading

norrisjeremy commented Apr 25, 2023

sameb commented Apr 25, 2023 •

edited

Loading

martin-g commented Apr 25, 2023 via email

sameb commented Apr 25, 2023

cdietrich commented May 5, 2023

sameb commented May 5, 2023

mkurz commented May 8, 2023 •

edited

Loading

hgschmie commented May 8, 2023

ben-manes commented May 8, 2023

GedMarc commented May 9, 2023 •

edited

Loading

sameb commented May 9, 2023

jakarta.inject support #1383

jakarta.inject support #1383

Comments

cogman commented Aug 20, 2020

tandr commented Mar 9, 2021 • edited Loading

GedMarc commented Mar 10, 2021

kashike commented May 24, 2021

d135-1r43 commented Jun 1, 2021

onacit commented Feb 9, 2022

Azimuts commented Oct 14, 2022 • edited Loading

trintaaho commented Dec 19, 2022

csisy commented Mar 17, 2023

xvik commented Apr 13, 2023

sameb commented Apr 21, 2023

sameb commented Apr 25, 2023 • edited Loading

norrisjeremy commented Apr 25, 2023

sameb commented Apr 25, 2023 • edited Loading

martin-g commented Apr 25, 2023 via email

sameb commented Apr 25, 2023

cdietrich commented May 5, 2023

sameb commented May 5, 2023

mkurz commented May 8, 2023 • edited Loading

hgschmie commented May 8, 2023

ben-manes commented May 8, 2023

GedMarc commented May 9, 2023 • edited Loading

sameb commented May 9, 2023

tandr commented Mar 9, 2021 •

edited

Loading

Azimuts commented Oct 14, 2022 •

edited

Loading

sameb commented Apr 25, 2023 •

edited

Loading

sameb commented Apr 25, 2023 •

edited

Loading

mkurz commented May 8, 2023 •

edited

Loading

GedMarc commented May 9, 2023 •

edited

Loading