-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Migrate to Jakarta EE 8 #4397
Conversation
This should probably be targeted at develop. |
Probably yes, but I suspect we cannot upgrade to Jakarta EE 8 because of no WireMock version supporting that. Seems like they went straight for Jakarta EE 9. |
Fwiw we use WireMock in a very limited part of the project only and despite me introducing it, I've never really been a massive fan of it. If we can rework those tests to use something else I don't mind just ripping WireMock out (not sure if I'm opening a can of worms here though)
…On Tue, 14 Feb 2023, at 04:43, Erik Godding Boye wrote:
> This should probably be targeted at develop.
>
Probably yes, but I suspect we cannot upgrade to Jakarta EE 8 because of no WireMock version supporting that. Seems like they went straight for Jakarta EE 9.
—
Reply to this email directly, view it on GitHub <#4397 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFR5SBFQM3QGPMU5CTQEZDWXJJBHANCNFSM6AAAAAAUQACMTQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
If wiremock is used in the spring-part, e.g https://rest-assured.io with springmockvc could be an alternative |
I'll support ripping WireMock out, mainly because it is tightly coupled with Java/Jakarta EE and Jetty. Maybe a spring-managed dependency could be used as a replacement - even in core modules - as this affects the test classpath only? Maybe create an issue for it? |
Maybe https://www.mock-server.com/ could be another alternative to (closer to) WireMock. I don't have any experience with https://rest-assured.io/, but it seems to solve a bit different use case than WireMock/MockServer. |
I created a POC draft PR for migrating to MockServer: https://github.com/eclipse/rdf4j/pull/4429/files It seems like we will get more verbose code, but the migration is fairly simple. I could finalize this if we decide to head in that direction. @abrokenjester @barthanssens @hmottestad WireMock seems to be a blocker for a couple of tasks at present..... |
3b9f0da
to
dbc818b
Compare
b504a6e
to
ff7e558
Compare
Further progress is currently blocked by #4439. Would be good to have that PR reviewed and merged. |
Probably also semi-blocked by #4437. At least it would be a lot simpler to upgrade Jetty (or migrate to Tomcat) if using JUnit Server. Actually, I think migrating to Tomcat for our test-servers would make a lot of sense because Elastic/Solr seem to depend on Jetty - which makes it harder to upgrade. Ref. the failing integration-tests: https://github.com/eclipse/rdf4j/actions/runs/4217370690/jobs/7321097966 |
7023906
to
b999878
Compare
a9a4daf
to
2778958
Compare
44da546
to
27991f0
Compare
9c3d835
to
43f3d8b
Compare
3c75595
to
115c43d
Compare
Wow, CI is finally green! A minor hack for the conflicting Jetty dependency pulled in from the Solr dependencies. I really really would like some input on how to get this change in somehow. So before I create a new PR and probably an issue, it would be very nice to know what you think:
I've found the following issues relevant to this PR: #3559 #4252 #4441 |
@erikgb as the branch develop is now targeting RDF4j 5.x I think that is the right branch to target. |
I am not sure if that will work. Jakarta EE 9 migrates all classes from |
Superseded by #4604 |
This is a draft PR suggesting migration to Jakarta EE 8, which is the first Jakarta EE release and the only one compatible with Java EE. I think this is a good first step towards migrating to Jakarta EE 9, which adds the additional complexity of the javax->jakarta API namespace move - which is what I am actually looking for. 😄
Relates to #3559
CC: @abrokenjester @hmottestad
Could this really be this simple, or are there some hidden complexities that I cannot see?
GitHub issue resolved: #
Briefly describe the changes proposed in this PR:
PR Author Checklist (see the contributor guidelines for more details):
mvn process-resources
to format from the command line)