NumberFormatException in TagSupport#tagOrder()
TomasHofman opened this issue · 4 comments
We have tooling that creates tags with commit ids in the name, e.g.:
[thofman@rama gradle-manipulator]$ git tag
repour-6829522e172f4326b1ec9bb4ef70e38328973134
repour-75df5fd8368fa8da9873fa5035082a7b85bc5a29
This breaks the versioning plugin.
The versioning plugin tries to extract a numeric trailing portion of the tag name and sort tags according to these numbers (there is also another round of sorting based on commit time). In this case the number it extracts is "38328973134", which is then cast to int
which fails with NumberFormatException, because the number is too large for the int
type.
Obviously this sorting logic doesn't fit our case, but that itself is not a problem for us. The problem is that the build fails.
Would it be possible to avoid the NFE in some way? E.g. by providing a way to disable this part of the sorting mechanism. Looking at the code it looks it cannot be avoided:
static int tagOrder(String tagPattern, String tagName) {
Matcher m = tagName =~ tagPattern
if (m.find()) {
int ngroups = m.groupCount()
if (ngroups < 1) {
throw new IllegalArgumentException("Tag pattern is expected to have at least one number grouping instruction: $tagPattern")
} else {
return m.group(1) as int
}
} else {
throw new IllegalStateException("Tag $tagName should have matched $tagPattern")
}
}
Technically we don't need to work with sorted tags at all, the line we are calling in our build is:
tasks {
"jar"(Jar::class) {
this.manifest {
attributes["Scm-Revision"]=versioning.info.commit // <=
...
}
}
}
but even that triggers the sorting.
Also, what I should have written first of all, thank you for a useful plugin ;-).
Hi @TomasHofman ,
Thanks for reporting this.
Can I ask why you need this plugin in the first place if you only need the commit? If you need only the current commit, I guess you could use a simpler plugin like https://github.com/ajoberstar/gradle-git ?
The versioning
plugin allows to manage your versions beyond the commit ID aspect.
Do I make sense? Or is there something I don't see?
Thanks,
Damien
Hello Damien,
yes, absolutely makes sense.
I asked around and nobody is really sure if we had any plans to use the plugin for anything beyond commit id. So it looks it looks the simplest thing is that we just use a different way of getting commit id.
Sorry for the noise and thank you for suggestions! ;-)