[I don't know anything about Travis, so this may be a non-starter.] The ASF Jenkins jobs can be set up with environment variables that point to different JDKs. If there is something similar for Travis, then the script could use those. It would then be up to the Travis maintainers to ensure that the variables are correctly maintained. Since they are the ones who install the JDKs, they are best placed to maintain the variables.
Or maybe there is some config file that provides the same info? If Travis does not provide such a feature, maybe someone should request it? On 4 August 2017 at 19:56, Amey Jadiye <ameyjad...@gmail.com> wrote: > Hi, > > Yes we are giving up the simplicity of travis but I see some advantages > over it, all of them are listed in my previous mail, let me try to put them > again. > > 1. Travis provides very limited JDK at this point [1] and travis builds can > become more flexible and we will have more control over the different > flavours, versions and vendors of jdk we wants to use with travis build > process. > > 2. Travis is very slow providing the different versions of jdk ATM. they > don't have ibmjava8 not sure when ibmjava9 will be there ? > > 3. Complexity of file is limited to just one parent file, and its very > generalised so we still have options to choose which jdk we want. > > 4. Script can contain specific version of stable JDK we want this gives > more control to us for quickly updating next minor version rather waiting > for Travis. > > 5. Other thing I'm proposing is to have this script as .travis.parent.sh and > we can keep it somewhere centralised http location and wget it and execute > from .travis.sh so core logic will have to maintain at single place, change > will be only in respective .travis.yml. > > This script is modified kepping in mind that this will be usefull to all > Commons components for their own specific needs and not onyl for text, Text > is just test project. Even I don't want EA to be the part of script, I was > just trying different options if anyone wants. > > Ex. for text I will have only below environment. > > env: > - JDK=7 > vendor=oracle > - JDK=7 > vendor=open > - JDK=8 > vendor=oracle > - JDK=8 > vendor=open > ECJ=true > - JDK=8 > vendor=ibm > - JDK=9 > vendor=oracle > - JDK=9 > vendor=ibm > > [1]. https://docs.travis-ci.com/user/languages/java/ > > Regards, > Amey > > On Fri, Aug 4, 2017 at 11:44 PM, Benedikt Ritter <brit...@apache.org> wrote: > >> I agree with Pascal. It's better to use Travis build in stuff. When IBM Jdk >> really become available, that would be quite nice, because that tends to >> cause failures. Regarding EA builds, I think it's good enough to test >> releases against them. Since EA builds may have regressions, this could >> lead to unstable builds. That's why I wouldn't make them part of my CI. >> >> Regards, >> Benedikt >> >> Pascal Schumacher <pascalschumac...@gmx.net> schrieb am Fr. 4. Aug. 2017 >> um >> 18:20: >> >> > Hello everybody, >> > >> > let me add some detail to what I mean by hard to maintain. >> > >> > The scripts contains links to specific jdk versions: >> > >> > >> > http://download.java.net/java/jdk9/archive/178/binaries/jdk- >> 9+178_linux-x64_bin.tar.gz >> > >> > http://download.java.net/java/jdk9/archive/178/binaries/jdk- >> 9+178_linux-x64_bin.tar.gz >> > >> > http://download.java.net/java/jdk8u152/archive/b05/binaries/ >> jdk-8u152-ea-bin-b05-linux-x64-20_jun_2017.tar.gz >> > >> > http://public.dhe.ibm.com/ibmdl/export/pub/systems/ >> cloud/runtimes/java/8.0.4.7/linux/x86_64/ibm-java-sdk-8.0- >> 4.7-x86_64-archive.bin >> > >> > 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 >> > variant. >> > >> > There is also a pull request to add the ibm jdk to travis: >> > https://github.com/travis-ci/travis-cookbooks/pull/874 and a travis >> > employee promised to take a look soon. So maybe travis will support the >> > ibm jdk out of the box soon. >> > >> > Cheers, >> > Pascal >> > >> > Am 03.08.2017 um 23:32 schrieb Rob Tompkins: >> > > Hello all, >> > > >> > > We have an open pull request from Amey ( >> > https://github.com/apache/commons-text/pull/61 < >> > https://github.com/apache/commons-text/pull/61>) 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 >> > >> > >> > >> > > > > -- > > --------------------------------------------------------------------- > > 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
