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

Added more relevant constraints to the quarkus-bom #26565

Merged
merged 1 commit into from
Jul 7, 2022

Conversation

aloubyansky
Copy link
Member

No description provided.

@quarkus-bot quarkus-bot bot added area/dependencies Pull requests that update a dependency file area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins labels Jul 5, 2022
@aloubyansky
Copy link
Member Author

@gsmet I added wildfly-elytron-* and bitbucket after talking to @sberyozkin

@@ -14,6 +14,7 @@
<packaging>pom</packaging>

<properties>
<bitbucket.version>0.7.12</bitbucket.version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one probably needs to be added to Dependabot? Or put together with the dependencies that need alignment if it needs to be aligned (together with comments indicating the need for alignment).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sberyozkin I added a direct dependency on jose4j to the module using its API directly. So it is both a direct dependency and a transitive dependency through io.smallrye:smallrye-jwt-build. Would you like to control it in the quarkus-bom or use whatever smallrye-jwt-build depends on? In the later case, perhaps we shouldn't add it to the BOM, unless you think the probability of conflicts will be high. smallrye-jwt-build is already managed, so if it comes only as a dependency of smallrye-jwt-build there won't be a problem if don't add it to the BOM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gsmet @sberyozkin I removed jose4j from this PR for now. Let's handle it separately from the rest.

@quarkus-bot

This comment has been minimized.

@quarkus-bot

This comment has been minimized.

@gsmet gsmet added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Jul 6, 2022
@quarkus-bot

This comment has been minimized.

@aloubyansky
Copy link
Member Author

The Infinispan client's HealthCheckTest is failing because it's not compatible with the Hibernate Search version we are using including in our BOM. It works with 6.0.8, while the version we are including is 6.1.5.

@quarkus-bot
Copy link

quarkus-bot bot commented Jul 6, 2022

Failing Jobs - Building deda35b

Status Name Step Failures Logs Raw logs
✔️ JVM Tests - JDK 11
JVM Tests - JDK 11 Windows Build Failures Logs Raw logs
✔️ JVM Tests - JDK 17
✔️ JVM Tests - JDK 18

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 Windows #

- Failing: extensions/mongodb-client/deployment 
! Skipped: extensions/liquibase-mongodb/deployment extensions/panache/mongodb-panache-common/deployment extensions/panache/mongodb-panache-kotlin/deployment and 8 more

📦 extensions/mongodb-client/deployment

io.quarkus.mongodb.NamedMongoClientConfigTest. - More details - Source on GitHub

java.lang.RuntimeException: 
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.mongodb.deployment.DevServicesMongoProcessor#startMongo threw an exception: java.lang.RuntimeException: java.lang.IllegalStateException: Previous attempts to find a Docker environment failed. Will not retry. Please see logs and check configuration

io.quarkus.mongodb.NamedReactiveMongoClientConfigTest. - More details - Source on GitHub

java.lang.RuntimeException: 
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.mongodb.deployment.DevServicesMongoProcessor#startMongo threw an exception: java.lang.RuntimeException: java.lang.IllegalStateException: Previous attempts to find a Docker environment failed. Will not retry. Please see logs and check configuration

<groupId>org.hibernate.search</groupId>
<artifactId>hibernate-search-util-common</artifactId>
<version>${hibernate-search.version}</version>
</dependency>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yrodiere could you have a look at this when you're back? It looks like we cannot enforce Hibernate Search's version properly when using Infinispan.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this comment specifically: #26565 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gsmet wdyt about merging it a figuring out the hibernate-search/infinispan compatibility separately? Given that the rest of the constraints aren't related to that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gsmet I can have a look but I'm not sure what I can do? The version of Infinispan bundled with Quarkus hasn't been updated to HSearch 6.1 yet. Infinispan's main branch has been upgraded, but I don't think it's been published yet.

The only immediate solutions I see are:

  1. Upgrading to a newer version of Infinispan; not sure there is one.
  2. Downgrading Hibernate Search; that doesn't seem wise.
  3. Accepting we won't have matching versions. And that people can't use both Infinispan embedded and the Hibernate Search extension in the same application.

In the future, there are a few possible strategies, none of them great:

  1. Accepting we won't have matching versions. And that people can't use both Infinispan embedded and the Hibernate Search extension in the same application.
  2. Never breaking any SPI in Hibernate Search, ever again.
  3. Waiting for Inifinispan to be released whenever we upgrade Hibernate Search, before upgrading in Quarkus.
  4. Shading Hibernate Search into Infinispan Embedded.

Personally I'd favor 4. It's really supposed to be an internal dependency of Infinispan after all, since they're working hard on hiding all Hibernate Search APIs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last time I checked there wasn't a more recent Infinispan version for us to upgrade to, unfortunately.

Never breaking the SPI (2) is a great one :) And if you do, a safe way would be to coordinate releases, so that there is combination of Hibernate Search and Infinispan that works, which is (3).

Shading is an option, although it may complicate CVE tracking and patch delivery. But maybe not that much.

As to how wise downgrading the HS version is, it depends on how often people will run into this issue, basically how critical it is to have a working combination of the two. I am not sure for long it has been broken and whether anybody has run into it yet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite all the complications, we shouldn't just let it go neither. Today we could document it as not being supported. Until one day we get one or more important use-cases that require both HS and Infinispan being present in the same app, at that moment we'll have to make it work somehow and starting from that moment, we will want to preserve compatibility and not have random breakages between releases. So thinking/preparing for that moment could be worth it.

@gsmet I don't think the rest of the changes should be blocked by this issue. Would you prefer to remove the comments I added about the HS/Infinispan issue from the BOM?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I will merge it, I was busy on other things.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not have random breakages between releases

It's not random, it's when necessary, on minor versions, in SPIs only, and that's a clearly established policy for all Hibernate projects. Let's not assume we're breaking stuff just because we don't care: we do :)

The exact reason we're having a problem is I'd been told in the past that there would not be any Infinispan Embedded in Quarkus, and since the HotRod (non-Embedded) client does not depend on Hibernate Search, the Hibernate Search dependency shouldn't have affected it at all.

So thinking/preparing for that moment could be worth it.

Certainly.

I'm back from PTO, so I'll be able to look further. First step would be to determine why the Hibernate Search dependency affects Infnispan at all; I thought Infinispan Embedded had been added to Quarkus without my knowledge, but that doesn't seem to be the case? It seems the error is really just in the HotRod client, which shouldn't be depending on Hibernate Search in the first place. I'll look into that.

What should I do to reproduce the issue; just uncomment those lines, build the relevant modules and run Quarkus + Infinispan integration tests?

Today we could document it as not being supported

Sure, documenting would be a good temporary solution.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, to reproduce uncomment the constraints and run io.quarkus.it.infinispan.client.HealthCheckTest.testHealthCheck, you can see the failures from the CI above. Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

For future reference, the problem was in the test dependencies rather than in the "main" dependencies. Guillaume addressed it here: #26647

@gsmet gsmet merged commit 8f7accd into quarkusio:main Jul 7, 2022
@quarkus-bot quarkus-bot bot added this to the 2.11 - main milestone Jul 7, 2022
@quarkus-bot quarkus-bot bot removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/dependencies Pull requests that update a dependency file area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/oidc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants