Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70357

Maven extensions under ${MAVEN_HOME}/lib/ext are not included in the classpath

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None

      If our understanding is correct,
      the following output from our Jenkins build,
      running on SSH Slave and Docker cloud,
      reveals that Maven extensions under /lib/ext folder are not considered

      Established TCP socket on 43567
      Copied maven35-agent.jar
      Copied maven35-interceptor.jar
      Copied maven3-interceptor-commons.jar
      [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
      <===[JENKINS REMOTING CAPACITY]===>���channel started
      Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -Dmaven.logging=byproject --builder smart -T 1C
      ...
      ...
      ...
      Using the MultiThreadedBuilder implementation with a thread count of ...
      

      This felt similar to Maven non-interactive mode (batch) prevent's project extensions loading

      However, we have proven that the relevant Docker image is equipped with the Maven extensions,
      by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder and Multithreaded Build Logging extensions being used and either with or without interactive mode enabled.

      Using the SmartBuilder implementation with a thread count of ...
      

      However, when we run the same through a Jenkins job of Maven nature,
      Maven falls back to standard mode:

      Using the MultiThreadedBuilder implementation with a thread count of ...
      

      Use of Maven extensions file didn't work either.

      Consequently, we cannot take full advantage of Maven parallel builds.

      This is most certainly related to a Maven Integration Plugin behavior.

          [JENKINS-70357] Maven extensions under ${MAVEN_HOME}/lib/ext are not included in the classpath

          Elias Balasis created issue -
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          reveals that Maven extensions under /lib/ext folder are not considered.

          {code}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}

          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.
          New: If our understanding is correct,
          the following output from our Jenkins build,
          reveals that Maven extensions under /lib/ext folder are not considered.
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          reveals that Maven extensions under /lib/ext folder are not considered.
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under /lib/ext folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{/opt/MAVEN_HOME/conf/logging}}, the behavior is the same, the default builder implementation is used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to Maven Integration Plugin behavior.
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under /lib/ext folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{/opt/MAVEN_HOME/conf/logging}}, the behavior is the same, the default builder implementation is used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to Maven Integration Plugin behavior.
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to Maven Integration Plugin behavior.
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under /opt/MAVEN_HOME/lib/ext,
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to Maven Integration Plugin behavior.
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to Maven Integration Plugin behavior.
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          only {{/conf/logging}} is considered.

          Consequently, Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to Maven Integration Plugin behavior.
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.

          Further study reveals this could be releated to the use of "-B" option which seems to be injected by Maven Integration Plugin unconditionally.
          see [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -B -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.

          Further study reveals this could be releated to the use of "-B" option which seems to be injected by Maven Integration Plugin unconditionally.
          see [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.

          Further study reveals this could be releated to the use of "-B" option which seems to be injected by Maven Integration Plugin unconditionally.
          see [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.

          Further study reveals this could be releated to the use of "-B" option which seems to be injected by Maven Integration Plugin unconditionally.
          see [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.

          Further study reveals this could be releated to the use of "-B" option which seems to be injected by Maven Integration Plugin unconditionally.
          see [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]
          see https://github.com/jenkinsci/maven-plugin/blob/maven-plugin-3.20/src/main/java/hudson/maven/MavenModuleSetBuild.java#L805
          see https://github.com/jenkinsci/maven-plugin/blob/maven-plugin-3.20/src/main/java/hudson/maven/MavenBuild.java#L911

          Can we please make this configurable?
          Elias Balasis made changes -
          Description Original: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code:java}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -Dmaven.logging=byproject --builder smart -T 1C
          {code}
          More precisely,
          the Takari Smart Builder extension,
          present under {{{}/opt/MAVEN_HOME/lib/ext{}}},
          is not included in the classpath
          {code:java}
          -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging
          {code}
          It seems only {{/conf/logging}} is considered
          and Maven falls back to standard mode.
          {code:java}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}
          Consequently, we cannot take full advantage of Maven parallel puilds.

          However,
          even after putting the extensions under {{{}/opt/MAVEN_HOME/conf/logging{}}}, the behavior is the same, the default builder implementation is still used.

          Also,
          we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used.

          This is feels most certainly related to a Maven Integration Plugin behavior.

          Further study reveals this could be releated to the use of "-B" option which seems to be injected by Maven Integration Plugin unconditionally.
          see [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]
          see https://github.com/jenkinsci/maven-plugin/blob/maven-plugin-3.20/src/main/java/hudson/maven/MavenModuleSetBuild.java#L805
          see https://github.com/jenkinsci/maven-plugin/blob/maven-plugin-3.20/src/main/java/hudson/maven/MavenBuild.java#L911

          Can we please make this configurable?
          New: If our understanding is correct,
          the following output from our Jenkins build,
          running on SSH Slave and Docker cloud,
          reveals that Maven extensions under {{/lib/ext}} folder are not considered
          {code}
          Established TCP socket on 43567
          Copied maven35-agent.jar
          Copied maven35-interceptor.jar
          Copied maven3-interceptor-commons.jar
          [projectname] $ /opt/JAVA_HOME_DEFAULT/bin/java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Daether.syncContext.named.factory=file-lock -Daether.syncContext.named.nameMapper=file-gav -Djava.awt.headless=true -cp /home/jenkins/maven35-agent.jar:/opt/MAVEN_HOME/boot/plexus-classworlds-2.6.0.jar:/opt/MAVEN_HOME/conf/logging jenkins.maven3.agent.Maven35Main /opt/MAVEN_HOME /home/jenkins/remoting.jar /home/jenkins/maven35-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43567
          <===[JENKINS REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /home/jenkins/workspace/.../pom.xml clean install -Dmaven.logging=byproject --builder smart -T 1C
          {code}

          This felt similar to [Maven non-interactive mode (batch) prevent's project extensions loading|https://stackoverflow.com/questions/38888712/maven-non-interactive-mode-batch-prevents-project-extensions-loading]

          However, we have proven that the relevant Docker image is equipped with the Maven extensions,
          by running a Docker container from it and the relevant Maven commands successfully, with the SmartBuilder extension being used and either with or without interactive mode enabled (-B).
          {code}
          Using the SmartBuilder implementation with a thread count of ...
          {code}

          However, when we run the same through a Jenkins job of Maven nature,
          Maven falls back to standard mode:
          {code}
          Using the MultiThreadedBuilder implementation with a thread count of ...
          {code}

          This is feels most certainly related to a Maven Integration Plugin behavior.

            Unassigned Unassigned
            eliasbalasis Elias Balasis
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: