Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Consider reverting change to revision attribute in pom #480

Open
snicoll opened this issue Dec 14, 2024 · 3 comments · May be fixed by #481
Open

Consider reverting change to revision attribute in pom #480

snicoll opened this issue Dec 14, 2024 · 3 comments · May be fixed by #481
Labels
Milestone

Comments

@snicoll
Copy link
Member

snicoll commented Dec 14, 2024

Please consider reverting #474 and everything that it caused. The purpose of the GitHub workflow is to make sure that things as much aligned as possible and each deviation from that makes Spring Retry special for no good reason.

The maven flatten plugin can easily be introduced to publish a POM that's more clean and without unnecessary information. That would be a plus as well.

@artembilan
Copy link
Member

Hey, Stephane!

Thank you for feedback!

So, my logic was like this:
If community complains about revision property, then indeed something is wrong.
Then it looks like this revision was introduced only for easier way to extract the project version during GHA release WF run.
Since there is a standard Maven way to get that info via mvn help:evaluate -Dexpression="project.version" -q -DforceStdout command, there is no reason in extra convenient property.

I'm not familiar with Maven flatten plugin, but introducing it just for revision property mitigation feels like an overhead in such a single module project.

And if you talk about alignment and deviations, there is the reusable workflows project which we use successfully in many places.
It might not be perfect, but it does exactly the same for many CI/CD processes and more.
I will be more than happy to migrate Spring Retry there as well. So, we would have one more project aligned and pointed only to a single place of truth or failure.

We may discuss this further offline.

@snicoll
Copy link
Member Author

snicoll commented Dec 18, 2024

If community complains about revision property, then indeed something is wrong.

Yeah, I am not denying that. I missed to add the last step in https://maven.apache.org/maven-ci-friendly.html, sorry about that.

Since there is a standard Maven way to get that info via mvn help:evaluate -Dexpression="project.version" -q -DforceStdout command, there is no reason in extra convenient property.

I disagree with the analysis. The revision property has been introduced to mimic many other projects that use it. The link that I've shared above explains the benefit of using such property. The property hasn't been only introduced as a way to to get the version when releasing.

And if you talk about alignment and deviations, there is the reusable workflows project which we use successfully in many places.

Sure, it's another reusable workflow you could use rather than this one, I don't have an opinion about that. But that's two different topic. Right now, it's neither.

@artembilan
Copy link
Member

Thank you for the link, Stephane!
Now I know more about Maven 😄

So, I'll revert to revision and will look into this:

If you like to install or deploy artifacts by using the above setup you have to use the flatten-maven-plugin

@artembilan artembilan added this to the 2.0.12 milestone Dec 18, 2024
artembilan added a commit to artembilan/spring-retry that referenced this issue Dec 18, 2024
Fixes: spring-projects#480

* Add `flatten-maven-plugin` to resolve properties
and remove unnecessary build info from the final POM of the artifact to install/deploy
@artembilan artembilan linked a pull request Dec 18, 2024 that will close this issue
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants