Migrate from javax to jakarta

[yamass]

People are more and more migrating to the newer EE versions (Jakarta). Jetty 11 has been out for more than a year and depends on jakarta. Spring 6 (release data: Q4 2022) will depend on jakarta. https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

I suggest you introduce two versions of gitlab4j-api: One depending on javax and one on jakarta, maybe on two different branches.

[mdindoffer]

@jabby Please, can we merge this change? The EE spec this repo depends on is ancient. We're using our own private fork to workaround classpath problems, but it's starting to be a real burden.

[Walti91]

@jabby is there any update on this? we are currently in the process of upgrading to spring boot 3 and would like to prevent having to do any workarounds like using a fork in order to keep using this library.

[marcelstoer]

Maybe discuss this in the context of #817 as it's a breaking change? I propose to create a 5.x branch that stays both on Java 8 and javax while master (for gitlab4j 6.x) moves to Java 11/17 and Jakarta. For a year or so all GitLab API fixes would have to be back-ported from master to the 5.x branch.

[jabby]

I like your idea @marcelstoer.

[edigu]

Coming from a greenfield Spring Boot 3.x project and just discovered that even the latest version of the gitlab4j-api can not be used within a spring boot 3 app.

I tried to add javax.ws.rs-api dependency (even if I expect more problems) to see the outcome:

<dependency>
  <groupId>javax.ws.rs</groupId>
  <artifactId>javax.ws.rs-api</artifactId>
  <version>2.1.1</version>
</dependency>

which ended up with compatibility errors:

	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:191) ~[spring-security-web-6.0.0.jar:6.0.0]
    ...
Caused by: java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    org/gitlab4j/api/GitLabApiClient.createApiClient()Ljavax/ws/rs/client/Client; @18: invokevirtual
  Reason:
    Type 'org/glassfish/jersey/client/JerseyClientBuilder' (current frame, stack[0]) is not assignable to 'javax/ws/rs/client/ClientBuilder'
  Current Frame:
    bci: @18
    flags: { }
    locals: { 'org/gitlab4j/api/GitLabApiClient', 'org/glassfish/jersey/client/JerseyClientBuilder' }
    stack: { 'org/glassfish/jersey/client/JerseyClientBuilder', 'java/lang/Class' }
  Bytecode:
    0000000: bb01 fa59 b701 fc2a b400 95b6 01fd 4c2b
    0000010: 12cf b602 0157 2b12 d5b6 0201 572a b402
    0000020: 0699 0013 2b2a b402 08b6 020a 2ab4 020e
    0000030: b602 1057 2a2b b602 14b5 00de 2ab4 00de
    0000040: b0                                     
  Stackmap Table:
    append_frame(@52,Object[#514])

	at org.gitlab4j.api.GitLabApi.<init>(GitLabApi.java:442) ~[gitlab4j-api-5.0.1.jar:na]
	at org.gitlab4j.api.GitLabApi.<init>(GitLabApi.java:389) ~[gitlab4j-api-5.0.1.jar:na]
	at org.gitlab4j.api.GitLabApi.<init>(GitLabApi.java:328) ~[gitlab4j-api-5.0.1.jar:na]

Is there any roadmap for jakarta migration or known workaround to use gitlab4j within spring boot 3?

[krusche]

we would also appreciate if this can be merged soon: maybe a 6.0 beta or release candidate can then be published on Maven for all users who want to upgrade to Spring Boot 3

[hemju]

Is there any update on this issue? Spring Boot 3 is the new standard, and the change from javax to jakarta was long overdue (and promoted). This PR only changes the package definition, so merging it shouldn't be a problem. Maybe Gitlab itself can jump in and help this project out.

[hemju]

@gmessner @jabby would you kindly give us some information about your plans of this project? From what I understand the community is ready to help with the project and maybe we can even get Gitlab to help/support this project.

[Korde-vaibhav]

Can we get spring boot 3 support soon ? we see there are few PRs already posted for fixing the same. you can at least issue a beta release.

[derkoe]

I like your idea @marcelstoer.

@jabby I have created a branch with all the changes for a 6.x release that works: master...derkoe:gitlab4j-api:6.0.x

Should I create another PR or do you want to continue on this?

[jabby]

@Korde-vaibhav it should happen this week.

@derkoe I will check your branch and let you know.

[freddiN]

Is there a chance this can me merged in the forseeable future?

Would be interesting to know if there are any hard blockers that prevent this from getting done with. We are currently holding back a spring boot 3 migration for this.

[hemju]

@jabby @derkoe any update on this?

[mydatascience]

Please fix it for 6.0 and merge the suggested changes

[julien-pal]

@jabby any update on this?

[Telamon-m]

@jabby any news on that topic? This incompatibilty makes it impossible for many users to use the gitlab4j-api in their applications because of the jakarta migration.
As mentioned by others: There are several folks from the community which would help here, so do I.

[hemju]

@jabby @derkoe ping on this issue. Could we get at least a response? What is the plan with moving forward here? I don't think ignoring the issue is the way to go.

[jmini]

So I have open an issue #926 to discuss how we could have a version 6.0.0 in parallel to the current work.

Feel free to give your opinion on the feature. Once feedback has been collected, we could move on with this PR.

[jmini]

I now have started to work on this, but I have opened a different PR to target 6.x.

Feel free to file comments on #947

---

In my opinion this PR can be closed.

[marcelstoer]

In my opinion this PR can be closed.

I agree but for now I would welcome a statement at the top of the README on main that describes the current plan as for 6.x, Jakarta and Spring Boot 3 (pointing people to the 6.x branch).

[jmini]

@marcelstoer :

Please check if the release 6.0.0-rc.1 works for you and give feedback, so that we know if we are on the good path for a 6.0.0 release.

Yes the readme of the main branch can be improved to mention the existence of the 6.x branch.

[freddiN]

I migrated to spring boot 3.0.5 and used 6.0.0-rc.1, works like a charm.

My usecase: Syncing our postman collections as jsons into our gitlab.