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

Maven incremental build trigger does not trigger all modules after changed groupId

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: maven-plugin
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      When we check the following option during we configure a Maven job:

      Build -> Incremental build - only build changed modules

      The feature works fine and only build the modules that were changed in the SCM.

      However, if we change the `groupId` of the project the modules will not be built ever more because the Maven plugin thinks that there are two activated versions of each module: the version with the old `groupId` and the version with the new `groupId`.

      Therefore, Maven plugin thinks that the `relative path` of both versions is the same and one of these is subsidiary of the other one. 

      Replication

      Please, let me show an example for explaining better the situation:

      1. We generate a maven project with three children modules like this: https://github.com/ironcerocloudbees/maven-modular

      2. We create a maven job setting this repository in the `Source Code Management` and clicking the `Incremental build - only build changed modules` option.

      3. We make a change in two modules (module 1 and module 2) (in the java files) and we build the maven job. The maven command run is the following:

      Executing Maven:  -B -f $JENKINS_HOME/workspace/maven1/pom.xml -amd -pl io.jitpack.test:module1,io.jitpack.test:module2 install
      

      That is correct, only module 1 and module 2 are called for building.

      4. We change the groupId of the project (changing the groupId properties in the pom.xml of all modules and in the parent module).

      5. We build the maven job. The maven command run is the following:

      Executing Maven:  -B -f $JENKINS_HOME/workspace/maven1/pom.xml -amd -pl io.jitpack.a:example-root,io.jitpack.a:module1,io.jitpack.a:module2,io.jitpack.a:module3 install
      

      Again this is correct because we have needed to change all modules (1, 2 and 3).

      6. We make a change in two modules (module 1 and module 2) (in the java files) and we build the maven job. The maven command run is the following:

      Executing Maven:  -B -f $JENKINS_HOME/workspace/maven1/pom.xml install
      

      This is wrong. The right command should include the following argument:

      -pl io.jitpack.test:module1,io.jitpack.test:module2
      

      7. Now, we create a new child module in the maven project (called module 4) and we build the maven job. The maven command run is the following:

      Executing Maven:  -B -f $JENKINS_HOME/workspace/maven1/pom.xml -amd -pl io.jitpack.a:module4 install
      

      From now on, let's make the change we make, only module 4 will always be built.

      Root cause

      I believe this issue occurs because in the method `getSubsidiaries()` of the class `MavenModule` we are getting all modules (using the `getParent().getModules()` method).

      /**
       * Computes the list of {@link MavenModule}s that are 'under' this POM filesystem-wise. The list doens't include
       * this module itself.
       *
       * <p>
       * Note that this doesn't necessary has anything to do with the module inheritance structure or parent/child
       * relationship of the POM.
       */
      public List<MavenModule> getSubsidiaries() {
          List<MavenModule> r = new ArrayList<MavenModule>();
          for (MavenModule mm : getParent().getModules())
              if(mm!=this && mm.getRelativePath().startsWith(getRelativePath()))
                  r.add(mm);
          return r;
      }
      

      I believe the line `for (MavenModule mm : getParent().getModules())` must be change by `for (MavenModule mm : getParent().getDisabledModules(false))` for tacking only the activated modules.

      I believe this method (`getSubsidiaries()`) is used only by `getChangeSetFor()`. So, we could process to study this fix.

      Kind regards,

        Attachments

          Activity

          There are no comments yet on this issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              ironcerocloudbees Ignacio Roncero Bazarra
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: