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

Maven Buildstep and Maven project are completely different

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core, (1)
      maven-plugin
    • None

      The configuration of a "Invoke top-level Maven targets" build step in a Freestyle project, and the configuration of the Build section in a Maven project type are so completely different, that I don't even know where to begin.

      Options are called differently, are in a different order, some are missing from the first, some are missing from the other. Imho, these should really be completely the same.

      Missing on one side:

      • Properties: this nice textarea is missing completely from the maven project type, instead we have to use -D... in a single-line textfield
      • Use private Maven repository: the freestyle version is missing the "local to executor" option
      • Run headless: only available in Maven project
      • Maven Validation level: only available in Maven project
      • Maven Version: the popup offers a "(default)" choice (whatever that is) in Freestyle, but not in Maven Project

      Naming inconsistencies:

      • JVM Options <-> MAVEN_OPTS: same thing, different names, also MAVEN_OPTS might sound to the unwary that you can put your properties here
      • "Goals" <-> "Goals and options": also it's an expandable textbox in Freestyle, but not in Maven project

      Different order/section:

      • "Goals" and "Pom" fields are swapped
      • "Use custom workspace": Freestyle: hidden in "Advanced project options", maven: in main Build section
      • "Build Environment": Freestyle: above the Build section, Maven: below the Build section

      There are some more options in Maven project, that only make sense there, so that's OK. But at least the rest should be identical.

          [JENKINS-17471] Maven Buildstep and Maven project are completely different

          Daniel Beck added a comment -

          Appears to be more of an enhancement request. These are completely independent implementations in different components, so some differences are to be expected.

          Daniel Beck added a comment - Appears to be more of an enhancement request. These are completely independent implementations in different components, so some differences are to be expected.

          Marc Günther added a comment -

          Having two completely independent implementations for doing the same thing does not really sound like a good design decision to me

          Marc Günther added a comment - Having two completely independent implementations for doing the same thing does not really sound like a good design decision to me

          Daniel Beck added a comment -

          It's not the same thing. One is a special, magical job type that hooks into the Maven process to be able to not require configuration and do lots of automatic magic. Requires special support in Jenkins for every major(ish) Maven release, and is difficult to debug according to Stephen Connolly: http://javaadventure.blogspot.de/2013/11/jenkins-maven-job-type-considered-evil.html

          The other is a nicer interface to the Maven command line call that just provides the Maven installation automatically if so configured.

          Both are included out of the box probably more for historical reasons than anything else. Jenkins tries hard to not break backwards compatibility.

          Daniel Beck added a comment - It's not the same thing. One is a special, magical job type that hooks into the Maven process to be able to not require configuration and do lots of automatic magic. Requires special support in Jenkins for every major(ish) Maven release, and is difficult to debug according to Stephen Connolly: http://javaadventure.blogspot.de/2013/11/jenkins-maven-job-type-considered-evil.html The other is a nicer interface to the Maven command line call that just provides the Maven installation automatically if so configured. Both are included out of the box probably more for historical reasons than anything else. Jenkins tries hard to not break backwards compatibility.

            Unassigned Unassigned
            marc_guenther Marc Günther
            Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: