Re: [all/travis-ci] Regarding potential Travis-CI solutions

[Amey Jadiye]

Closed PR.

On Mon, Aug 7, 2017 at 2:12 AM, Amey Jadiye  wrote:

> looking at inclination of community I will be closing the PR without
> expecting merge after a week by 14th August 2017 unless someone see it's
> useful.
>
> Reference will be there in closed PR list on github so if someone need it
> in future it will be there.
>
> Regards,
> Amey
>
>
> On Fri, Aug 4, 2017, 3:02 AM Rob Tompkins  wrote:
>
>> Hello all,
>>
>> We have an open pull request from Amey (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

Re: [all/travis-ci] Regarding potential Travis-CI solutions

[Amey Jadiye]

looking at inclination of community I will be closing the PR without
expecting merge after a week by 14th August 2017 unless someone see it's
useful.

Reference will be there in closed PR list on github so if someone need it
in future it will be there.

Regards,
Amey

On Fri, Aug 4, 2017, 3:02 AM Rob Tompkins  wrote:

> 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

Re: [all/travis-ci] Regarding potential Travis-CI solutions

[sebb]

[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  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  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  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 

Re: [all/travis-ci] Regarding potential Travis-CI solutions

[Amey Jadiye]

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  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  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 

Re: [all/travis-ci] Regarding potential Travis-CI solutions

[Benedikt Ritter]

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  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
>
>
>

Re: [all/travis-ci] Regarding potential Travis-CI solutions

[Pascal Schumacher]

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 
) 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

[all/travis-ci] Regarding potential Travis-CI solutions

[Rob Tompkins]

Hello all,

We have an open pull request from Amey 
(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