commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pascal Schumacher <>
Subject Re: [all/travis-ci] Regarding potential Travis-CI solutions
Date Fri, 04 Aug 2017 16:19:51 GMT
Hello everybody,

let me add some detail to what I mean by hard to maintain.

The scripts contains links to specific jdk versions:

These have to be updated regularly, because what good is it to test 
against yesterdays EA versions? (They actually are already out of date :().

Commons-text just uses a very stable and small parts of the jdk so I do 
not think it is very likely that something will break on a different 

There is also a pull request to add the ibm jdk to travis: and a travis 
employee promised to take a look soon. So maybe travis will support the 
ibm jdk out of the box soon.


Am 03.08.2017 um 23:32 schrieb Rob Tompkins:
> Hello all,
> We have an open pull request from Amey (
<>) proposing a fairly complicated but
quite nice travis-ci build solution (taken from the jacoco project) that accommodates building
on JDK7, JDK8, JDK8-ea, EclipseJava, JDK9-ea, as well as IBMJava-8. To accommodate building
on all of these different versions of Java, we do however need to make the travis-ci build
a good deal more complex.
> As the two reviewers on the pull request, Pascal and myself, have mildly differing opinions
on the complexity-value trade off here, with Pascal’s opinion being: "…[T]his is overkill.
I don't think commons-text needs to be tested against the eclipse java compiler and early
access versions of java 8 and 9. The script looks difficult to debug and maintain.” And
my perspective is that this could be a test piece for using this elsewhere in commons.
> To me, the argument for simplicity is always quite compelling, to the point that I’m
mostly willing to let go of using the jacoco travis-ci pattern. But I figured I would, before
making any decisions, see what the community thinks generally about this possible travis-ci
build script.
> Cheers,
> -Rob

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message