help me https://github.com/apache/pulsar/issues/22325

Moved it to discussions since it doesn't seem to be a bug. I replied: https://github.com/apache/pulsar/discussions/22328?converting=1#discussioncomment-8876861

2 questions here: 1. Will the LTS release get BOM POMs going forward? Is this planned? I did not see a scope in the PIP. 2. Are the dependencies shaded? If not, is this in plan? Typical scenario is very common libraries like apache commons or jackson are often dependencies in client libraries and they would have different versions than the ones our applications or other libraries use. This can lead to different versions being encountered in the classpath and leading to unexpected issues. I have faced this in the past with AWS library and had to move to the AWS fat jar library to avoid this. Also, not sure what the recommended practice here would be; only that such a provision makes it easier for users of the library (although this could mean lots of classes being loaded in runtime and the runtime being a bit bloated)

1. Will the LTS release get BOM POMs going forward? Is this planned? I did not see a scope in the PIP.

@Daniel This isn't currently planned, for 3.0.x, but it's always possible to propose that, although it's not very usual that we add "features" to already released maintenance branches. What would be your use case? (As a workaround for 3.0.x version alignment, In Gradle builds, it's possible to align versions even without BOMs. Just in case you are a Gradle user.)

2. Are the dependencies shaded?

pulsar-client

,

pulsar-admin

and

pulsar-client-all

are all shaded. Shading isn't used for Jackson annotations since that would cause annotations on user classes to not being detected. There are a few other exceptions such as Protobuf, which doesn't seem to have a known solution for shading (issue https://github.com/apache/pulsar/issues/22263 , shading related comment: https://github.com/apache/pulsar/issues/22263#issuecomment-1997056963) that would work with user classes generated with protoc.

pulsar-client-original

and

pulsar-admin-original

are the unshaded versions and it's necessary to use them in certain cases when there are issues with Jackson and Protobuf.

Thank you @Lari Hotari! We are currently in the process of migrating from a very old pulsar version to the latest LTS. I just wanted to know what the best way would be to update the client in our codebase after that. We do use gradle but I am fairly new to it. I will look into the gradle feature that you suggesting.

With Gradle, without BOMS, you can use resolutionStrategy to enforce a specific version, SO answer https://stackoverflow.com/a/54395634 . Gradle's resolutionStrategy's dependencySubsititution can be used to replace the shaded dependencies with unshaded dependencies (pulsar-client -> pulsar-client-original). That is needed in some use cases, as mentioned before. btw. Sharing this slightly unrelated tip since we are talking about shading and Gradle. if you happen to do your custom shading with Gradle's shadow plugin, it's recommended to use the unshaded dependencies pulsar-client-original and pulsar-admin-original you will also need the workaround mentioned in https://github.com/apache/bookkeeper/issues/3511 .

Thank you.. will look into this