This message was deleted.

That would also be my guess, that you set the version to snapshot version after that plugin is applied. I usually set the version in the

gradle.properties

file, then I have no such problems.

what workaround can i use here? my problem is that i am using the axion-release-plugin, so it is the thing that resolves the version dynamically(i don't use that just yet, it's hardcoded). so that would not work with the gradle.properties

If the

axion-release

plugin calculates this version on being applied, make sure it is applied before that plugin, or actually apply it in that plugin before using the calculated version. I - personally - would say don't use it, as I hate dynamically calculated versions that depend on the version control being present. This prevents proper reproducible and VCS independent builds. You cannot build a source export, you cannot build in a Git worktree if JGit is used for Git access, ..... Other than that, you can of course use the good old - but very bad -

afterEvaluate { ... }

so that eventually the version was maybe already set.

I hear your points, though they seem too theoretical for my use, whereas what I am sick of is versions in code, auto merge\release merges, developers having to think about versions (when in reality they don't matter for many apps). And triggering releases off of git tags seems to be pretty common these days Aside from that, the simplistic problem is: if I add in a plugin, a calculation on the repo based on version, then when I apply the plugin, it's not recalculating that version...I guess. Just a basic functionality that I would expect to be able to achieve for publishing, someone else must have encountered that before or fixed it.. Because it's a pretty basic use for a convention plugin The irony is that maven does this easily

It's also common that people build fat jars. Doesn't make them any less an abuse of Java functionality and major bad practice with man pitfalls that could easily be circumvented by not doing that non-sense. 😄

possibly; but it's debatable and there's pros/cons Regardless, even without that concept, i still should be able to get the plugin to just listen to what i'm telling it to in the project. and deploy the thing to the right snapshot vs release url. it is a tricky issue to search for too

Well, as I said, you probably have to use

afterEvaluate

and cross fingers. 🙂

okay i'll give it a shot. sometimes...gradle perplexes me. it's like it all seems good sometimes and then you get 1 requirement that other toolchains handle just fine and it falls off the rails, no examples and workarounds only. the kind of thing where im' asking "uhh..did..nobody actually test this?". anyone converting a maven project should've hit that issue