On 24 August 2018 at 14:53, sebb <seb...@gmail.com> wrote: > On 24 August 2018 at 14:46, Gary Gregory <garydgreg...@gmail.com> wrote: >> On Fri, Aug 24, 2018 at 7:41 AM Benedikt Ritter <brit...@apache.org> wrote: >> >>> Hi, >>> >>> Am Fr., 24. Aug. 2018 um 09:06 Uhr schrieb Benedikt Ritter < >>> brit...@apache.org>: >>> >>> > >>> > >>> > Am Do., 23. Aug. 2018 um 20:12 Uhr schrieb sebb <seb...@gmail.com>: >>> > >>> >> Huh? >>> >> >>> >> Looks like the failure is due to Clirr is reporting some breaks; not >>> >> sure how that can depend on the Java version. >>> >> >>> > >>> > Maybe related to Java 8 default methods? I'm just guessing here... Need >>> to >>> > dig into this on the weekend. >>> > >>> >>> It looks like this is related to Clirr handling default methods the wrong >>> way. So we probably need to fix clirr in order to use it. I found a mirror >>> of the code on GitHub in Emmanuel Bourg's account [1]. We could probably >>> try to fix clirr, but I'd like to explore whether it would be okay to drop >>> clirr entirely and only use jacimp instead (which seems to work with Java >>> 8). >>> >> >> It's not clear to me that japicmp is maintained either, it has not had a >> release in a long time. >> >> Should we bring in Clirr as a Commons project if the license allows?
Not sure tha's possible, as it uses LGPL: http://clirr.sourceforge.net/license.html > It would be good to adjust the Maven plugin to distinguish source and > binary issues. > At present the HTML report combines these. > >> Gary >> >> >>> Regards, >>> Benedikt >>> >>> [1] https://github.com/ebourg/clirr/issues/1 >>> >>> >>> > >>> > Benedikt >>> > >>> > >>> >> >>> >> >>> >> On 23 August 2018 at 18:37, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >> > This has to do with the Java version used to run the build... I've >>> seen >>> >> it >>> >> > locally but just switched Java version to avoid it. >>> >> > >>> >> > Gary >>> >> > >>> >> > On Thu, Aug 23, 2018, 11:18 Benedikt Ritter <brit...@apache.org> >>> wrote: >>> >> > >>> >> >> Hi, >>> >> >> >>> >> >> it looks like the master branch build for commons-collections is >>> >> failing >>> >> >> for a while now [1]. Does anybody have the time to look into this? >>> >> >> >>> >> >> Benedikt >>> >> >> >>> >> >> [1] https://travis-ci.org/apache/commons-collections/jobs/404183011 >>> >> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>> >> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org