b153-Switch JAX-RS API dependencies to jakarta.ws.rs-api

[jhemm2]

Description

Updated dependencies and imports to switch to jakarta EE9 (javax vs jakarta)

remaining issues before we are ready for review

• running with jetty:run (instead of jetty:run-war) results in error

[INFO] jetty-12.0.7; built: 2024-02-29T21:19:41.771Z; git: c89aca8fd34083befd79f328a3b8b6ffff04347e; jvm 17.0.10+7
[WARNING] Failed startup of context oeje10mp.MavenWebAppContext@5683a326{ROOT,/,b=[file:///C:/Users/.../lyo/refimpl/src/server-rm/src/main/webapp/, file:///C:/Users/.../lyo/refimpl/src/server-rm/target/jetty_overlays/oauth-webapp-6_0_0-SNAPSHOT_war/],a=STOPPED,h=oeje10s.SessionHandler@6723626f{STOPPED}}{file:///C:/Users/.../lyo/refimpl/src/server-rm/src/main/webapp/}
java.lang.IllegalArgumentException: Unable to mount FileSystem from unsupported URI: jar:file:///C:/Users/.../.m2/repository/org/apache/jena/apache-jena-libs/4.8.0/apache-jena-libs-4.8.0.pom!/
	at org.eclipse.jetty.util.resource.FileSystemPool.mount(FileSystemPool.java:128)
	at org.eclipse.jetty.util.resource.ResourceFactoryInternals$CompositeResourceFactory.mountIfNeeded(ResourceFactoryInternals.java:268)

• Need to cleanup dependencies to avoid the following warnings relating to jakarta.servlet.jsp.jstl-api-3.0.0 I have removed a number of other warnings through changes in the dependencies. These need to be reviewed to make sure we have the right approach.

[WARNING] jakarta.servlet.jsp.jstl.fmt.LocalizationContext scanned from multiple locations: jar:file:///C:/Users/....m2/repository/jakarta/servlet/jsp/jstl/jakarta.servlet.jsp.jstl-api/3.0.0/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/fmt/LocalizationContext.class, jar:file:///C:/Users/...git/lyo/refimpl/src/server-rm/target/server-rm/WEB-INF/lib/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/fmt/LocalizationContext.class
[WARNING] jakarta.servlet.jsp.jstl.sql.ResultSupport scanned from multiple locations: jar:file:///C:/Users/....m2/repository/jakarta/servlet/jsp/jstl/jakarta.servlet.jsp.jstl-api/3.0.0/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/sql/ResultSupport.class, jar:file:///C:/Users/...git/lyo/refimpl/src/server-rm/target/server-rm/WEB-INF/lib/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/sql/ResultSupport.class
[WARNING] jakarta.servlet.jsp.jstl.tlv.ScriptFreeTLV scanned from multiple locations: jar:file:///C:/Users/....m2/repository/jakarta/servlet/jsp/jstl/jakarta.servlet.jsp.jstl-api/3.0.0/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/tlv/ScriptFreeTLV.class, jar:file:///C:/Users/...git/lyo/refimpl/src/server-rm/target/server-rm/WEB-INF/lib/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/tlv/ScriptFreeTLV.class
[WARNING] jakarta.servlet.jsp.jstl.core.IndexedValueExpression scanned from multiple locations: jar:file:///C:/Users/....m2/repository/jakarta/servlet/jsp/jstl/jakarta.servlet.jsp.jstl-api/3.0.0/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/core/IndexedValueExpression.class, jar:file:///C:/Users/...git/lyo/refimpl/src/server-rm/target/server-rm/WEB-INF/lib/jakarta.servlet.jsp.jstl-api-3.0.0.jar!/jakarta/servlet/jsp/jstl/core/IndexedValueExpression.class

Checklist

• This PR adds an entry to the CHANGELOG. See https://keepachangelog.com/en/1.0.0/ for instructions. Minor edits are exempt.
• This PR was tested on at least one Lyo OSLC server (e.g. manual workflow on Lyo Sample and OSLC RefImpl) or adds unit/integration tests.
• This PR does NOT break the API

Issues

Closes #153 ; Closes #00

(#153)

[berezovskyi]

@jhemm2 thank you for contributing! Quite a nice round PR number for such an important contribution.

There is no need to reopen a PR. I just enabled the build so that you can get the build to run every time you push your changes and check how close are we to be ready to merge the PR.

I closed #501 and please proceed with this PR. Don't worry about the build failing, it's only to help us to not merge the PR into master until we know that it will build.

[berezovskyi]

@Jad-el-khoury the ECA check has passed: https://api.eclipse.org/git/eca/status/gh/eclipse/lyo/500

[Jad-el-khoury]

Brilliant!

[Jad-el-khoury]

Don't worry about the build failing, it's only to help us to not merge the PR into master until we know that it will build.

But the build is failing because there is a problem, no? @berezovskyi !
https://github.com/eclipse/lyo/actions/runs/8266742369/job/22615459955

[jhemm2]

Don't worry about the build failing, it's only to help us to not merge the PR into master until we know that it will build.

But the build is failing because there is a problem, no? @berezovskyi ! https://github.com/eclipse/lyo/actions/runs/8266742369/job/22615459955

I have fixed this issue with my last commit, let's see what the next build says

[Jad-el-khoury]

The last build has passed.
What is the overall status of the PR @jhemm2 ! Do you think it is ready for review, or should we place it in "Draft" mode to start with?

[jhemm2]

Great. I tried my best to update all the affected dependencies and imports but as this change is quite large, I would appreciate someone to do some more verification and review on it.
Is there any chance to release this in a side-branch, some kind of beta version, to be able to test lyo when used in external applications, e.g. with springboot3 applications?

[danlz]

@jhemm2 You're the man 👍

[Jad-el-khoury]

Given that we are on the 6.0.0.SNAPSHOT, I believe we should be able to push the changes straight to main - once we are satisfied. You already have a branch for people to download and test with.

I can try to test on some servers on my side as well. If we both manage to make it work, we can start the review process and merge the change to master.

@berezovskyi ! are we missing anything in the process?
@danlz can you possibly test?

[danlz]

@Jad-el-khoury yep

[berezovskyi]

Let's make a 6.0.0.alpha1 release before merging to provide projects already tracking 6.0 SNAPSHOT a bit of a fallback before the Jakarta switch?

Releasing Jakarta change in 6.0 sounds good.

[berezovskyi]

We shall also update refimpl to jakarta, which requires Lyo Designer update. Usually we run simple integration tests on refimpl to chexk bigger lyo changes.

[Jad-el-khoury]

@jhemm2 ! I would like to start with migrating the Lyo Reference Implementation as a way to validate/review this large change.

Assume you have done a similar implementation, it would greatly simplify my job If you can share any hints or outline the steps needed to migrate? I planed to analyze your change here, but anything that makes this job go faster would be great.

[jhemm2]

@Jad-el-khoury I am using only the oslc-client in my project. We are using the client to read write RM data via OSLC.
Locally, I have now installed the adapted 6.0.0-SNAPSHOT version. In my project will upgrade the dependency and replace the javax imports with the jakarta ones .
This week, I can do some testing on the new client. As I have never used all the other modules like the server, I cannot really test them.

[jhemm2]

I have just updated my project with the following dependencies and successfully ran my integration tests. The integration tests authenticate to IBM DOORS Classic as well as IBM DNG and reads/ writes modules and requirements.

lyo.version=6.0.0-SNAPSHOT
java.version=17.0.10
springboot.version=3.2.3
jersey.version=3.1.5
jakarta.xml.bind-api=4.0.2
jaxb-impl=4.0.5

So from my side, at least the client part looks good.

[danlz]

I have tested with Spring Boot 3.2.1 and Jersey 3.1.5.
Java 17.
I've tested the server side and it was fine.

[Jad-el-khoury]

Thanks for the info @jhemm2 ! This will be helpful.
Then I know that we need to do some more testing on the server side of the code.

@danlz! Really cool to hear that it works with Spring Boot. Do you think you can contribute with a example server that uses Spring Boot? Our reference Implementation do not rely on Spring Boot. It would be useful for the community to show that Lyo works with Spring (I do get that question often)

[danlz]

@Jad-el-khoury It is not a rocket science ;)
The key point is spring-boot-starter-jersey.
I'll prepare something next week.

[Jad-el-khoury]

I have migrated the remaining Lyo projects to Jakarta.
I used this useful Eclipse Transformer Maven Plugin.
@jhemm2 ! Did you use this or something similar for hte first commit, or did you do it manually?

I have only tested very quickly on 1 sample server as per this PR.

One issue remains. I wonder if anyone has any tips on how to deal with the very old oauth projects.
See https://github.com/eclipse/lyo/blob/master/server/oauth-core/pom.xml#L31

I could manually run the following to migrate the jar files. But how can we introduce into our maven build?
java -jar <path-to-org.eclipse.transformer.cli-0.5.0-distribution\org.eclipse.transformer.cli-0.5.0.jar> oauth-20100527.jar -o

This link might be useful but I could not get it to work yet
https://dzone.com/articles/best-practices-to-deal-with-javax-to-jakarta-migra

[Jad-el-khoury]

The oauth problem is the reason the build fails, so no surprises.

[Jad-el-khoury]

And @berezovskyi I was expecting problems with Jena. I did not test properly yet but there were no complains.

I noticed some special repos for Jena in the pom files.
You might need to update me on the status and way forward with that?

[danlz]

As @berezovskyi said, JSTL is no longer shipped with servers. Maybe you have to use a newer version of the jetty-maven-plugin?

We have added JSTL to Tomcat.

[Jad-el-khoury]

Thank you for your input. I have a proposal which seems to work. Please see the last 2 commits (combined) from this PR.

Do you think the below "default" is acceptable, or should it be the other way around?

By default, we only include the jstl-api with "provided" scope.

• This removes all warnings when running with jetty-maven-plugin (using 11.0.20 which is latest)
• This makes some containers fail (I am testing with cargo-maven3-plugin, using both tomcat10x & jetty12x)

To include the jstl implementation (and jstl-api without provided scope) - run with "with-jstl-impl" profile.

• All setups work fine.

For what it's worth, here are my tests before I came up with this solution. I believe it confirms your thoughts. Interesting though that Jetty12x behaves differently under this Cargo plugin.

If I only include jstl-api

• jetty-maven-plugin: Works, with just 4 warnings
• Cargo with jetty12x or tomcat10x - fails

If I invlude both jstl-api and jstl

• jetty-maven-plugin: Works,with many many warnings.
• Cargo with jetty12x or tomcat10x - works

If I include both jstl-api and jstl (with scope "provideed")

• jetty-maven-plugin: Works, with NO warnings.
• Cargo with jetty12x or tomcat10x - falis

[Jad-el-khoury]

If you think these last changes are acceptable, I believe this PR is ready for a final review (Special attention to all changes in the pom.xml files).
We have already relesaed Lyo 6.0.0.Alpha, so we can safely merge to master.

[berezovskyi]

@Jad-el-khoury in re jstl deps:

My view is that we shall include -api (provided is fine for server projects but client in a standalone env will break, but it will need extra impl deps anyway in the downstream project).

And then for tomcat we can include it in a profile (in LynxD), like in https://github.com/eclipse/lyo/blob/master/pom.xml#L92 (instead of specifying <build> stuff, we'd instead add an extra <dependencies> entry) and then https://github.com/oslc-op/refimpl/blob/master/.github/workflows/maven-acceptance.yml#L135 will be instead mvn -B package --file src/pom.xml -Ptomcat.

[Jad-el-khoury]

Isn't that the same as what I have already implemented?

[berezovskyi]

Yep, didn't notice. Left a question in the referenced PR.

[berezovskyi]

FYI, I pushed this PR into b153-migrate-jaxrs-api-to-jakarta on this repo to be able to kick off integration tests on other repos. Ignore that branch and keep using jhemm2:b153-migrate-jaxrs-api-to-jakarta to push PR updates.

[berezovskyi]

https://github.com/oslc-op/refimpl/actions/runs/8498710257 tests oslc-op/refimpl#198

• root services requests are failing with 503 errors

https://github.com/OSLC/lyo-samples/actions/runs/8498707134 tests lyo-samples master (specifically the client project)

• passes because it was still targeting 5.2.0-SNAPSHOT
• https://github.com/OSLC/lyo-samples/actions/runs/8498767441 runs tests on Switch to Lyo 6 OSLC/lyo-samples#142 with Lyo from this PR

[berezovskyi]

The refimpl tests are still failing with a 503 error: https://github.com/oslc-op/refimpl/actions/runs/8574115331/job/23500242159

[Jad-el-khoury]

The refimpl tests are still failing with a 503 error: https://github.com/oslc-op/refimpl/actions/runs/8574115331/job/23500242159

Only RM was updated, so no suprises there. But if we are confident that we are almost done (and you already reviewed LyoDesigner changes). I can then re-generate all Ref-impl servers and test again.

[berezovskyi]

Now I understand. Yes, let's update the other servers because otherwise this PR is ready to merge. If we keep those tests broken, they will just break CI pipeline and will make it harder to use tests in general.

I will check LyoD changes now if any further input from my side is needed. All looks good.

[berezovskyi]

Thanks Jad, tests now pass: https://github.com/oslc-op/refimpl/actions/runs/8575876036/job/23505766712

[Jad-el-khoury]

Thanks Jad, tests now pass: https://github.com/oslc-op/refimpl/actions/runs/8575876036/job/23505766712

I tried to re-run but it failed. Is it the change in the DOckerfiles that was missing?

[berezovskyi]

I tried to re-run but it failed. Is it the change in the DOckerfiles that was missing?

Yes, I think so. The values you parametrised the job with seemed OK.

[berezovskyi]

but this is the Lyo PR :) yes, we should start with it. LGTM

[Jad-el-khoury]

but this is the Lyo PR :) yes, we should start with it. LGTM

Yes, I noticed that I am getting the 2 PRs confused. We are done here.

[danlz]

@Jad-el-khoury Example of Lyo and Spring Boot integration. The example uses Jakarta version of Lyo.
https://github.com/danlz/lyo-in-spring-boot

[berezovskyi]

Thanks @danlz, added your sample to the README table: a30c7da

[danlz]

In the long run you should think of a Spring Boot starter for Lyo.

[berezovskyi]

@danlz that's indeed interesting, filed #524 for this. In the past we were considering a custom maven archetype for the type of adapters we produce now but there was not enough interest.