Re: Major Updates

[Roman Shaposhnik <ro...@shaposhnik.org>]

Hi Arnaud!

you're bringing up some good points. Let me ask you this, though:
do you think your concerns would be take care of if we had a way
to instruct whatever version of JDK we're using to generate 7
bytecode via -target 7 -source 7 ?

Thanks,
Roman.

On Fri, Dec 30, 2016 at 9:44 AM, Arnaud Launay <as...@launay.org> wrote:
> Hello,
>
>
> Le Fri, Dec 30, 2016 at 06:03:42PM +0100, Olaf Flebbe a écrit:
>> > https://www.linkedin.com/pulse/installing-openjdk-8-tomcat-debian-jessie-iga-made-muliarsa
>> what Do you want us to tell ? We are already doing this.
>
> For the record, my request to still be able to compile bigtop
> with JDK7 is based on the following elements:
>
> - JDK 8 is apparently less officially supported on 2.7:
> https://wiki.apache.org/hadoop/Roadmap
> hadoop-2.7: jdk7 at minima, jdk8 seems supported since october
> hadoop-2.8: supports both JDK 7 and 8
> hadoop-3: supports *only* jdk8
>
> - the second one is a bit more "company policy": we do not want
>   to deploy backports, unless absolutely necessary. It does not
>   matter if on the compiling server we have to use backports to
>   add some stuff (maven 3.3 for example), BUT not on the
>   production servers. Those are on Debian stable, using JDK7,
>   with no backports, and thus we want (need...) to compile bigtop JDK7.
>
> - I saw some strange things here are there with code compiled
>   with JDK8 and running under JDK7 that I absolutely do not want
>   to see for our hadoop pile :)
>
> - last (but not least), the whole thing came from gradle being
>   unable to download stuff using Cloudflare SSL: BIGTOP-2633
>   Olaf used a nuclear device (upping to java8) to kill a fly:
>   upgrading gradle to 2.12 was the only thing necessary. This is
>   now done: BIGTOP-2648
>
> So, unless the whole thing is on hadoop 2.8, I'd vote to stay on
> JDK7. However, as Olaf stated, preparing for other jdk (8, 9,
> Windows^W) using a variable which unless defined would default to
> JDK8 (or 7, as you wish) might be a better long-term solution.
>
>
> Hence, what about something like
> BIGTOP_JDK=7
> ./gradlew deb
>
> and something like this in do-component-build:
>
> if [ "${BIGTOP_JDK:=8}" == "8" ]; then
>         MAVEN_ADDITIONAL="-Dadditionalparam=-Xdoclint:none"
> fi
>
> and later
>
> mvn -DskipTests (...) \
> ${MAVEN_ADDITIONAL} \
> clean site install assembly:single "$@
>
>
>
> I have no idea how to manage bigtop.bom though:
>         'jdk' { version = '1.8'; version_base = version }
> nor build.gradle
>         def final langLevel = "1.7"
> nor packages.gradle
>         classpath 'org.eclipse.jgit:org.eclipse.jgit.java7:3.6.2.201501210735-r'
>
>
> Maybe a few sed's at the beginning of gradlew ?
>
>
>         Arnaud.

Re: Major Updates

[Arnaud Launay <as...@launay.org>]

Le Tue, Jan 03, 2017 at 05:32:09PM -0800, Roman Shaposhnik a écrit:
> you're bringing up some good points. Let me ask you this, though:
> do you think your concerns would be take care of if we had a way
> to instruct whatever version of JDK we're using to generate 7
> bytecode via -target 7 -source 7 ?

IMHO, no: the whole point is to compile (and run) the whole stack
using the same JDK. This is the only way I'm sure things don't
get mixed up -- trying to use a JDK 8 with a different
target/source seems to me much more trouble and probably
more maintenance, too. Plus the fact that you'll never be 100%
sure that everything has the correct settings passed...


If you have a look at the patches I sent earlier, I hope you'll
find them non-intrusive, the default stays with java 8, and it
permits to choose a different one with a single environment variable.

I built the full bigtop stack, with those patches and
BIGTOP_JDK=7 defined (well, the full deb target at least), today,
without a glitch.

	Arnaud.