-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add Docs: smallrye-pulsar cannot publish message in sample Quarkus project #40628
Comments
/cc @Ladicek (smallrye), @jmartisk (smallrye), @phillip-kruger (smallrye), @radcortez (smallrye) |
@ozangunalp is it a dependency that we declare? If so would it be better if we were explicit about wanting the jar in the pom file? |
@gsmet It is a transitive dependency. Maven resolves it correctly to jar but not Gradle. |
Yeah if it comes as a transitive dependency, I think I would rather try to ping the upstream projects so that they explicitly require a Of course, that will take time and in the meantime, we could document the workaround. |
Hi @ozangunalp, @gsmet, I think this 2 org.apache.bookkeeper dependencies (circe-checksum and cpu-affinity) should be in sync with the pulsar-client.version define in quarkus. |
But if they are transitive dependencies, they should come with versions supported by the components dragging them, right? |
yes but more we delegate this to upper stream more work and errors we will have to set the correct version. Example, the app is using quarkus 3.10, app doesn't know which version of pulsar-client is used and so they doesn't know the org.apache.bookkeeper dependencies. If you document it , each time quarkus upgrade the pulsar client you will have to update the doc, migration doc ... And quarkus users will have to read the migration guide and apply the changes. And syncing in quarkus will avoid a lot of late error in multiple apps that doesn't know the glue behind the pulsar extension. |
I agree with this. The upstream Apache Pulsar project manages that Bookkeeper dependency version. Unless there is a clear conflict between some core dependencies that will pull in Quarkus, I am against managing them in Quarkus. This isn't because of anything we do in Quarkus, but how Gradle resolves the dependency. I'll check the Pulsar project for a fix and update Quarkus docs with the workaround. |
@humcqc yeah that's why I favor a fix upstream to use the proper dependency in Gradle too. Because you seem to suppose that it would be easy for us to keep track of things but we are handling a gazillion of dependencies. If we had to manage them all, that would just be a major maintenance issue for us. So I agree that the situation is not ideal but if upstream can be fixed to actually handle Gradle properly, everything will be fine on your side without adding an additional maintenance burden on us. |
yes ideally Apache Pulsar Client should handle it correctly. But my remark is that the sync of the documentation of the workaround with the correct version is the same as the maintenance of the dependency itself. But it's fine for me, I understand your point with all the dependencies you already have to handle. I hope you will not forgot to update the workaround documentation and the migration guide with the correct version. Do you think you can add a gradle native test in quarkus, or if you already have one , add a pulsar test case. And do you think quarkus should add the workaround when we create an app with the cli : |
What I hope is that we will be able to drop the documentation soon enough (but I'm a dreamer :)). |
Unfortunately, we cannot add Gradle tests for every Gradle corner case, especially if it only affects native as testing native is very slow. At least, with proper doc and the discussion you started, people will find pointers to the solution relatively easily. |
thanks @ozangunalp @gsmet for the quick replies, @ozangunalp could you link this issue and #40390 with the pulsar one. And you can close #40390 |
Description
Hello,
because of smallrye/smallrye-reactive-messaging#2567 (comment), the current Quarkus Documentation (https://quarkus.io/guides/pulsar-getting-started and https://quarkus.io/guides/pulsar) for smallrye-reactive-pulsar does not lead to a working project when Gradle is used.
The Documentation should mention that when Gradle is used, the following workaround has to be implemented smallrye/smallrye-reactive-messaging#2567 (comment).
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: