This message was deleted.

I don't know any of these options. But my personal opinion is, that any procedure that requires a specific SCM to build the version string is bad. Imho if you export sources to a zip, unpack it somewhere, and build, you should get a proper result. As long as it is just special tasks like release actions that take information to construct a version that is then written to some file that is committed or something like that, that's ok. But if the version is purely calculated on-the-fly from the VCS and you cannot build without the VCS, then I personally consider that highly questionable. I usually just have the version in

gradle.properties

and the release tasks remove the

-SNAPSHOT

before release, create a commit, do the release, then increase the patch (or if given another part) version and add

-SNAPSHOT

, then do another commit. And if I do a change that warrants minor or major version increase, then I increase it right before or together with these changes manually as appropriate.

I agree that you should be able to build it on the fly, particularly locally. I think all of these solutions allow that and that is my requirement as well. For my perspective, the versions aren't a huge deal and I don't want those in my code. They seem to result in extra version commits and release commits, and I basically see them as monotony, I think they do. No good to be in code I've seen a few people's best practices in DevOps to be to not do that and I agree with it. I think the version is an implementation detail, and most of the time you don't care about it. And therefore, having it in the code doesn't matter. You still have the functional code aspects. And you could always override the version if you must

🤷

i do appreciate your discussion though as i try to find the best approach for my problems

I use nebula.release which calculates version from git repo state and has tasks to add release/rc tag. Then build pipeline just use these tags to publish the release

I migrated a project from Maven to Gradle a while back, and I landed on the Gradle Nexus Publish plugin (https://github.com/gradle-nexus/publish-plugin) and the Allegro Axion Release plugin (https://github.com/allegro/axion-release-plugin). These most closely resembled the Maven plugins I'd been using previously, which made the transition a bit easier. There may be more Gradle-y approaches, but this combination has been working for me.

Yup, I have liked axion, seems to work well. Btw what do you use for maven settings? Do you have info on what happens to settings.xml with Nexus security, or... is there a more gradle friendly way?

AFAIK,

settings.xml

and

toolchains.xml

are fully supported. I have the paths to several JDKs and the credentials for publishing releases thru Sonatype OSS specified in these files. Also, I'm able to post updates to version references in my README file on GitHub as part of the release process.