• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • None
    • Platform: All, OS: Linux

      Because Hudson runs an embedded version of Maven the user is unable to pass
      MAVEN_OPTS when Maven is invoked. This problem was encountered when trying to
      pass heap arguments to Maven for a project that exceeded the 60mb default during
      compilation. The result was a StackOverflow compilation error during build.

          [JENKINS-396] Unable to set MAVEN_OPTS for embedded Maven

          Fixed in 1.93.

          Note to myself:

          When options like -verbose:gc is added, which causes VM itself and not Java code
          to print out some data, it prints out data to stdout and that corrupts the
          binary communication stream between Hudson and maven process.

          This happens despite the fact that the maven process sets System.setOut(),
          because JVM code is not affected by this — it keeps writing to file descriptor
          0, and that is still stdout.

          -verbose:gc seems to write to stdout, so one possibility is to use stderr for
          the communication channel, although there's equal chance that JVM will write to
          stderr.

          Framing protocol (like special frame-in/out character) over stdout won't work
          because the output from JVM can occur concurrently to the Java thread.

          Marking the issue closed for now. Will re-evaluate this later.

          Kohsuke Kawaguchi added a comment - Fixed in 1.93. Note to myself: When options like -verbose:gc is added, which causes VM itself and not Java code to print out some data, it prints out data to stdout and that corrupts the binary communication stream between Hudson and maven process. This happens despite the fact that the maven process sets System.setOut(), because JVM code is not affected by this — it keeps writing to file descriptor 0, and that is still stdout. -verbose:gc seems to write to stdout, so one possibility is to use stderr for the communication channel, although there's equal chance that JVM will write to stderr. Framing protocol (like special frame-in/out character) over stdout won't work because the output from JVM can occur concurrently to the Java thread. Marking the issue closed for now. Will re-evaluate this later.

            Unassigned Unassigned
            spooky36 spooky36
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: