Created attachment 710817 [details] dev-java:stringtemplate-4.0.8-r1:20210523-203128.log =dev-java/stringtemplate-4.0.8-r1 fails tests. (Version 4.0.8 passed its tests when it was last built, but that was 2016, 2018, and 2019 on my three machines.) Here's what looks like the relevant section of the build log (the full build log and emerge --info will be attached): 1) testRendererForGroup(org.stringtemplate.v4.test.TestRenderers) org.junit.ComparisonFailure: expected:<datetime: 7/5/05[,] 12:00 AM> but was:<datetime: 7/5/05[] 12:00 AM> at org.junit.Assert.assertEquals(Assert.java:117) at org.junit.Assert.assertEquals(Assert.java:146) at org.stringtemplate.v4.test.TestRenderers.testRendererForGroup(TestRenderers.java:64) 2) testRendererWithPredefinedFormat2(org.stringtemplate.v4.test.TestRenderers) org.junit.ComparisonFailure: expected:<...esday, July 5, 2005 [at 12:00:00 AM Pacific Daylight Time] > but was:<...esday, July 5, 2005 [12:00:00 AM PDT] > at org.junit.Assert.assertEquals(Assert.java:117) at org.junit.Assert.assertEquals(Assert.java:146) at org.stringtemplate.v4.test.TestRenderers.testRendererWithPredefinedFormat2(TestRenderers.java:107) 3) testDateRendererWithLocale(org.stringtemplate.v4.test.TestRenderers) org.junit.ComparisonFailure: expected:<12 de [j]unho de 2012> but was:<12 de [J]unho de 2012> at org.junit.Assert.assertEquals(Assert.java:117) at org.junit.Assert.assertEquals(Assert.java:146) at org.stringtemplate.v4.test.TestRenderers.testDateRendererWithLocale(TestRenderers.java:361) 4) testRendererWithPredefinedFormat(org.stringtemplate.v4.test.TestRenderers) org.junit.ComparisonFailure: expected:< datetime: 7/5/05[,] 12:00 AM > but was:< datetime: 7/5/05[] 12:00 AM > at org.junit.Assert.assertEquals(Assert.java:117) at org.junit.Assert.assertEquals(Assert.java:146) at org.stringtemplate.v4.test.TestRenderers.testRendererWithPredefinedFormat(TestRenderers.java:90)
Created attachment 710820 [details] emerge-info.txt
the tests pass fine with openjdk-11 but fail with openjdk-8. obviously the formatting of the strings changed between these two java versions. imo it's better that the tests work fine with the newer java version rather than with the old one. probably the best solution for this is to detect java version being used (https://stackoverflow.com/questions/2591083/getting-java-version-at-runtime#2591122) and set the expected string in the tests accordingly.
(In reply to Miroslav Šulc from comment #2) > the tests pass fine with openjdk-11 but fail with openjdk-8. obviously the > formatting of the strings changed between these two java versions. imo it's > better that the tests work fine with the newer java version rather than with > the old one. > > probably the best solution for this is to detect java version being used > (https://stackoverflow.com/questions/2591083/getting-java-version-at- > runtime#2591122) and set the expected string in the tests accordingly. Latest upstream https://github.com/antlr/stringtemplate4/releases/tag/4.3.1 has version detection built-in: https://github.com/antlr/stringtemplate4/blob/d6eb444bb4a4c386d9be8c844892659b0eae679c/test/org/stringtemplate/v4/test/TestRenderers.java
Thanks for pointing out the change upstream. I downloaded commit 3ea94a870b6e139399abbf932da1dfa2f9bd37e3 as a patch and placed it in /etc/portage/patches/dev-java/stringtemplate-4.0.8; it applied cleanly, and the package built, passed its tests, and installed properly.
thank you both, gonna fix it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2419e959eba7ba4945452325216df3ce7c0b1bf7 commit 2419e959eba7ba4945452325216df3ce7c0b1bf7 Author: Miroslav Šulc <fordfrog@gentoo.org> AuthorDate: 2021-05-29 15:58:15 +0000 Commit: Miroslav Šulc <fordfrog@gentoo.org> CommitDate: 2021-05-29 15:58:33 +0000 dev-java/strimgtemplate: fixed tests in 4.0.8-r1 Closes: https://bugs.gentoo.org/791718 Package-Manager: Portage-3.0.19, Repoman-3.0.3 Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org> .../files/stringtemplate-4.0.8-fix-tests.patch | 72 ++++++++++++++++++++++ .../stringtemplate/stringtemplate-4.0.8-r1.ebuild | 1 + 2 files changed, 73 insertions(+)
(In reply to Miroslav Šulc from comment #5) > thank you both, gonna fix it. Why not push to 4.3.1 from PR https://github.com/gentoo/gentoo/pull/21018?
i had a look at it in the morning and i don't get the fix tbh so have to have a look at it. imo dropping the registration of the needed jar is not a solution. as far as i understand it, only splitting antlr as i described in another bug is the appropriate fix, but i might misunderstood something.
(In reply to Miroslav Šulc from comment #8) > i had a look at it in the morning and i don't get the fix tbh so have to > have a look at it. imo dropping the registration of the needed jar is not a > solution. as far as i understand it, only splitting antlr as i described in > another bug is the appropriate fix, but i might misunderstood something. Splitting antlr didn't help at all. The root cause in fact was that registration line. Removed it and all is fine. If I'm reading [1] correctly registration is for run-time dependency what in the present case something obviously is not. Otherwise removal of that line would have broken something. [1]https://github.com/gentoo/gentoo/blob/master/eclass/java-utils-2.eclass#L1234-L1242
