Add Spring Cloud Stream version as part of message headers produced

[sobychacko]

Adding the Spring Cloud Stream version as part of the message header is convenient for easier debugging of issues.

[omercelikceng]

@sobychacko If the issue is available, I would like to try to solve it. Let me give you brief information on how to do it.

Using the spring boot maven plugin, I will create the build-info.properties file under the META-INF directory at build time. Then I will inject this resource as a bean. And before sending the data, I will add it to the header. If you don't like the solution, I can think of another solution.

[sobychacko]

@omercelikceng You can certainly work on the issue if you have the bandwidth. I am not sure if we want to use the boot maven plugin that way at build time in the framework. Usually, we don't include the boot maven plugin as part of the framework build, but is used by the applications to create a boot app. We don't want to accidentally create uber-jars from the framework. We probably can get this information differently and attach that to the jar manifest.

[omercelikceng]

@sobychacko OK, I'll think of another way. But I didn't understand what you mean in the following sentence.(Word I don't understand: bandwidth) Did you mean to ask if I've worked on this topic before?

You can certainly work on the issue if you have the bandwidth.

[sobychacko]

You can certainly work on the issue if you have the bandwidth.

I meant, if you have the time, go ahead and work on the issue:-)

[omercelikceng]

Bant genişliğiniz varsa kesinlikle sorun üzerinde çalışabilirsiniz.

Demek istediğim, vaktiniz varsa devam edin ve konu üzerinde çalışın :-)

Ok thank you very much. Sorry for my bad English knowledge. :) I still need to learn some words. Please excuse me. I will work on this issue and write you my opinion.

[sobychacko]

No worries. Please let us know if you have any questions on this issue.

[omercelikceng]

@sobychacko Hello.
I have completed my development and I would like to ask a few questions.

While the project is being built, I save the relevant Spring Cloud Stream version in the Manifest.mf file.
And I get the Spring Cloud Stream version from this file.
Since I found a solution using the manifest file, I tried to try all the build methods. (fat jar, shaded jar, war vb.)

My code works successfully in the following cases.
1- I create a fat jar with spring-boot-maven-plugin
2- I create a war with spring-boot-maven-plugin.

But it is necessary to consider the following situations in detail.
1- If I create a shaded jar with the shaded plugin, the MANIFEST file is created only for the main project.
And since there is no MANIFEST file specific to the spring cloud stream jar, I cannot get the correct version.
I saw that in a shaded jar, instead of a MANIFEST file, a pom.properties file specific to the spring cloud stream jar is created.
So I can use the pom.properties file.
However, when I create a shaded jar, a MANIFEST file is not created for the spring cloud stream because we are in a third party position.

However, special situations may occur here. This pom.properties file may not be created depending on how the developer builds.
So, from what I have observed, it seems that it is not right to trust MANIFEST.MF or pom.properties files.
What path should I follow? I saw that there are plugins that generate a class that contains a version. Maybe if I use these it would be a better solution. Can you help me?

Or should I give the developer a message like the one below and ignore the situations I explained? "No manifest file or pom.properties file found in the jar. Please review the build method."

[sobychacko]

@omercelikceng Sorry for the delay in replying to you. I see that this is not a trivial problem to solve. I wonder if there is a more straightforward way to address this rather than going with the manifest route. We will explore if there is a solution and get back to you. In the meantime, please let us know if you can think of a better solution.

[omercelikceng]

@sobychacko.. No problem. I researched and found another solution. I can generate a class containing the version using the maven-antrun-plugin at compile time. What do you think about this solution? However, in this solution, the compile time of spring-cloud-stream will increase slightly.

[sobychacko]

@omercelikceng That might not be a bad idea. How intrusive is the code for doing that? I want to keep the changes for this very minimal. @artembilan and I have briefly discussed this issue today, and he was also thinking about something along these lines, i.e., coming up with a static properties file with the version.

[olegz]

We can get this info by parsing the JAR file name. We control it and we know that version is always going to be part of it.

URL url = AbstractBinder.class.getProtectionDomain().getCodeSource().getLocation();
// parse the url

[artembilan]

See also org.springframework.core.SpringVersion impl.

It is probably may fail in case of shading, however in this case we may just fall back and don't provide such a null value for SCST version header.
Just because it is not a standard SCST artifact, you are on your own to supply that value yourself.

[omercelikceng]

We can get this info by parsing the JAR file name. We control it and we know that version is always going to be part of it.

URL url = AbstractBinder.class.getProtectionDomain().getCodeSource().getLocation();
// parse the url

Hello @olegz. Thank you very much for your interest. Actually, I developed my code as you said. But when I do it this way, the problems I mentioned above occur when it is a shaded jar.

Problems:
#2814 (comment)

[omercelikceng]

See also org.springframework.core.SpringVersion impl.

It is probably may fail in case of shading, however in this case we may just fall back and don't provide such a null value for SCST version header. Just because it is not a standard SCST artifact, you are on your own to supply that value yourself.

Hello @artembilan. Thank you very much for your interest. I couldn't fully understand some of what you wrote. Please excuse me if I have rewritten what you already wanted to say. Just wanted to check.

I can do it this way. But when I generate shaded jar, the version is not null, we get the version of the main project. So I can't get the version of spring cloud stream. In this case, I need to check to understand that the value I got is the wrong version(main project version). I can do this like this(implementationTitle = "spring-cloud-stream"). But I'm not sure if this is a reliable way.

But I can do whatever you say. Could you please check me? I will get the version as in the org.springframework.core.SpringVersion method. If I cannot get the version(shaded-jar), I will not publish the version information in the header. Should I implement the implementation this way?

We gave up on implementing it this way, right?(#2814 (comment))

[artembilan]

I see that SpringBootVersion has it explicitly set.
The source code for that is like this: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot/src/main/javaTemplates/org/springframework/boot/SpringBootVersion.java.

They have a Gradle task for that template: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot/build.gradle#L153-L159

So, you might be not wrong going with something what could be done from Maven to modify such a template on project build.
I doubt that you do shading against source code, so this one should be reliable way to go.

However the final solution is up to @olegz as he is a lead of the project.