Skip to content
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

Post Quarkus 3.7 dependency alignment #26535

Closed
shawkins opened this issue Jan 26, 2024 · 4 comments · Fixed by #26788
Closed

Post Quarkus 3.7 dependency alignment #26535

shawkins opened this issue Jan 26, 2024 · 4 comments · Fixed by #26788

Comments

@shawkins
Copy link
Contributor

shawkins commented Jan 26, 2024

A breakdown of dependency issues following the quarkus upgrade:

Versions where we trail quarkus - may need individual issues:

  • bc-fips to 1.0.2.4 - exhibited classloading problems
  • liquibase to 4.25.1 - even after updating CustomLockService, there is still a test failure
  • osgi to 6.0 - didn't build successfully

Versions where we are ahead of quarkus, and that are used for more than tests:

Versions where we are even with quarkus, but have our own property:

  • slf4j - used only for an additional test dependency not covered by the quarkus bom
  • infinispan - used for more than tests and need the version to import the infinispan bom

Versions where we are trail quarkus, and that are used for more than tests, but seem to upgrade without an issue:

  • resteasy
  • wildfly-elytron

And a lot of test related dependencies / overlap - mostly drivers, but also awaitility, hamcrest, and testcontainers. Driver versions cannot be removed because we reference them as variables in our tests to switch between databases.

Originally posted by @shawkins in #26203 (comment)

@shawkins
Copy link
Contributor Author

Unfortunately with the exception of a couple of test dependencies it does not look like we can easily remove the versions we are referencing.

@vmuzikar
Copy link
Contributor

Related issue: #21356

@shawkins
Copy link
Contributor Author

shawkins commented Feb 5, 2024

@vmuzikar should an issue be created for the osgi upgrade? And/or would that fall under the core's responsibility?

@vmuzikar
Copy link
Contributor

vmuzikar commented Feb 6, 2024

should an issue be created for the osgi upgrade? And/or would that fall under the core's responsibility?

I'd say yes and yes. (CC @mposolda)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants