Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-2649

Default Java8 blocks default debian jdk

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.2.0
    • Component/s: build, debian
    • Labels:
    • Environment:

      Debian 8, Java 7

      Description

      Hello,

      By default, the last Debian, Jessie (8) comes with java7. java8 is available from backports, but we don't want to use backports on all our servers.

      Would it be possible somehow to keep both versions working to compile and use bigtop with the same runtimes ?

      Right now, I found a few problems with the current git and java7:

      • Javadoc 7 does NOT like "-Xdoclint:none"
      • kite checks if the used jdk is matching the one from bigtop.bom

      Compiling is still ongoing, I'll report here if I find anything else.

      Right now, my biggest concern is the bigtop.bom stack definition:

      bigtop {
      /** Base Configuration of the mirror and archives */
      version = "1.2.0-SNAPSHOT"
      stack {
      'jdk'

      { version = '1.8'; version_base = version }

      'scala'

      { version = '2.11.8'; version_base = version }

      }

      I have no idea if it's possible to have something like;
      'jdk'

      { version = [ '1.7', '1.8' ]; version_base = version }

      or
      'jdk'

      { version = /^1\.(7|8)$/'; version_base = version }

      or something like that, to allow bigtop to be constructed with both versions of the JDK.

        Activity

        Hide
        oflebbe Olaf Flebbe added a comment -

        Thank you very much! Committed!

        Show
        oflebbe Olaf Flebbe added a comment - Thank you very much! Committed!
        Hide
        asl Arnaud Launay added a comment -

        new format-patch patch enclosed

        Show
        asl Arnaud Launay added a comment - new format-patch patch enclosed
        Hide
        oflebbe Olaf Flebbe added a comment -

        And BTW: it is ok to leave the old files attached to the ticket. Anyone reading it can follow the discussions at a later time better.

        Show
        oflebbe Olaf Flebbe added a comment - And BTW: it is ok to leave the old files attached to the ticket. Anyone reading it can follow the discussions at a later time better.
        Hide
        oflebbe Olaf Flebbe added a comment - - edited

        +1, but may I ask you to add a git format-patch rather a patch file to the ticket?

        We are doing statistics of the commits, therefore we think it is important to get the contributors name into the log, not the committers name.

        And please use the BIGTOP-2649: Default Java8 blocks default debian jdk as commit subject in order to get the link between JIRA Ticket and commit.

        Thanks!

        Show
        oflebbe Olaf Flebbe added a comment - - edited +1, but may I ask you to add a git format-patch rather a patch file to the ticket? We are doing statistics of the commits, therefore we think it is important to get the contributors name into the log, not the committers name. And please use the BIGTOP-2649 : Default Java8 blocks default debian jdk as commit subject in order to get the link between JIRA Ticket and commit. Thanks!
        Hide
        asl Arnaud Launay added a comment -

        here it is

        Show
        asl Arnaud Launay added a comment - here it is
        Hide
        oflebbe Olaf Flebbe added a comment -

        Yep, please squash the commits into one.

        Show
        oflebbe Olaf Flebbe added a comment - Yep, please squash the commits into one.
        Hide
        asl Arnaud Launay added a comment -

        I can, but you asked me git format-patch the previous one, so I'm a bit lost... ?

        Show
        asl Arnaud Launay added a comment - I can, but you asked me git format-patch the previous one, so I'm a bit lost... ?
        Hide
        oflebbe Olaf Flebbe added a comment - - edited

        Hi Arnaud Launay . The patch LGTM. However, somehow there is a policy One JIRA - One Patch. The Subject Issue should match the JIRA.

        Could you please collapse your patches into one ?

        Thanx.

        Anyone else looking into this patch, too?

        Show
        oflebbe Olaf Flebbe added a comment - - edited Hi Arnaud Launay . The patch LGTM. However, somehow there is a policy One JIRA - One Patch. The Subject Issue should match the JIRA. Could you please collapse your patches into one ? Thanx. Anyone else looking into this patch, too?
        Hide
        asl Arnaud Launay added a comment -

        Given nobody objected on the ML, patches included.

        Show
        asl Arnaud Launay added a comment - Given nobody objected on the ML, patches included.
        Hide
        oflebbe Olaf Flebbe added a comment -

        And btw. Please subscribe to dev@bigtop.apache.org , if your are not already. We are getting into discussions how to handle changes like these.

        Show
        oflebbe Olaf Flebbe added a comment - And btw. Please subscribe to dev@bigtop.apache.org , if your are not already. We are getting into discussions how to handle changes like these.
        Hide
        oflebbe Olaf Flebbe added a comment -

        Yes, please propose something. One environment variable to rule all the JDK switching. Please be generic as possible.

        Show
        oflebbe Olaf Flebbe added a comment - Yes, please propose something. One environment variable to rule all the JDK switching. Please be generic as possible.
        Hide
        asl Arnaud Launay added a comment -

        do you want me to create it ?

        Show
        asl Arnaud Launay added a comment - do you want me to create it ?
        Hide
        asl Arnaud Launay added a comment -

        I think that on the infrastructure side, it might be difficult to find a "one size fits them all"... I don't care having openjdk8 in jdk.pp forced by pinning or otherwise, as long as I can still do it "by hand" and use jdk7 to compile bigtop.

        If the compiler person doesn't care, the current jdk.pp is perfectly fine IMHO. I would just maybe add a warning somewhere indicating that bigtop is compiled with jdk8, and thus the servers running it /should/ use jdk8 too. I saw a few strange things running jdk8 compiled software on jre7 machine :/

        Show
        asl Arnaud Launay added a comment - I think that on the infrastructure side, it might be difficult to find a "one size fits them all"... I don't care having openjdk8 in jdk.pp forced by pinning or otherwise, as long as I can still do it "by hand" and use jdk7 to compile bigtop. If the compiler person doesn't care, the current jdk.pp is perfectly fine IMHO. I would just maybe add a warning somewhere indicating that bigtop is compiled with jdk8, and thus the servers running it /should/ use jdk8 too. I saw a few strange things running jdk8 compiled software on jre7 machine :/
        Hide
        oflebbe Olaf Flebbe added a comment -

        And BTW. Is apt-pinning openjdk 8 from backports only o.k. for you ?

        Show
        oflebbe Olaf Flebbe added a comment - And BTW. Is apt-pinning openjdk 8 from backports only o.k. for you ?
        Hide
        oflebbe Olaf Flebbe added a comment -

        I propose you to introduce an environment variable to several of the do-components-build to switch between JDK8, JDK7 and – beware – JDK9 . Please try not to detect the JDK at runtime, this will break on different platforms. It should be declared.

        For your usecase it can be handled by Setting the environment variable externally.

        Wiring this environment variable together with bigtop.bom and packages.gradle / build.gradle is a different task which can be handled by a different JIRA.

        Thanks for this discussion!

        Show
        oflebbe Olaf Flebbe added a comment - I propose you to introduce an environment variable to several of the do-components-build to switch between JDK8, JDK7 and – beware – JDK9 . Please try not to detect the JDK at runtime, this will break on different platforms. It should be declared. For your usecase it can be handled by Setting the environment variable externally. Wiring this environment variable together with bigtop.bom and packages.gradle / build.gradle is a different task which can be handled by a different JIRA. Thanks for this discussion!
        Hide
        asl Arnaud Launay added a comment -

        Concerning the doclint, what about something like that in do-component-build:

        Unable to find source-code formatter for language: bash. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
        MAVEN_ADDITIONAL=`if [[ $JAVA_HOME == *"8"* ]]; then echo "-Dadditionalparam=-Xdoclint:none"; fi
        
        mvn -DskipTests (...) \
        ${MAVEN_ADDITIONAL} \
        clean site install assembly:single "$@ 
        

        Regarding that backport, it seems (I don't use that part anyway) that jdk.pp does of course only installs jdk8, but it installs the apt source.list for debian backports – and this is the thing we try not to use – not really a concern for us though, as we don't use it.

        Concerning the configurable JDK, I've no idea how to do it: the arcane of the gradle/bom files are too intricate for me

        Show
        asl Arnaud Launay added a comment - Concerning the doclint, what about something like that in do-component-build: Unable to find source-code formatter for language: bash. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml MAVEN_ADDITIONAL=` if [[ $JAVA_HOME == * "8" * ]]; then echo "-Dadditionalparam=-Xdoclint:none" ; fi mvn -DskipTests (...) \ ${MAVEN_ADDITIONAL} \ clean site install assembly:single "$@ Regarding that backport, it seems (I don't use that part anyway) that jdk.pp does of course only installs jdk8, but it installs the apt source.list for debian backports – and this is the thing we try not to use – not really a concern for us though, as we don't use it. Concerning the configurable JDK, I've no idea how to do it: the arcane of the gradle/bom files are too intricate for me
        Hide
        oflebbe Olaf Flebbe added a comment -

        Hi Arnaud Launay.

        The issues you are listing are exactly the things I "fixed" in order to get the distribution run on Java8.

        Before going into the details: No, I do not recommend to have backports enabled for all packages. My intention was that only openjdk-8 was installed from backports. If this is not the case this should be fixed.

        I am open to have the compile time JDK configurable. Right now it is a mess. I would like to have to configuration of the JDK in use by bigtop.bom.

        Show
        oflebbe Olaf Flebbe added a comment - Hi Arnaud Launay . The issues you are listing are exactly the things I "fixed" in order to get the distribution run on Java8. Before going into the details: No, I do not recommend to have backports enabled for all packages. My intention was that only openjdk-8 was installed from backports. If this is not the case this should be fixed. I am open to have the compile time JDK configurable. Right now it is a mess. I would like to have to configuration of the JDK in use by bigtop.bom .

          People

          • Assignee:
            asl Arnaud Launay
            Reporter:
            asl Arnaud Launay
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development