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

Incremental build doesn't work in a maven2 aggregation project with Cleacase

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • maven-plugin
    • None
    • Windows XP machine with maven2 and Clearcase as SCM.

      I'm using Hudson on Windows and Clearcase as SCM.

      My maven2 project has a aggregation pom in the root of the Clearcase Vob and several module poms in the folder beneath this root folder.
      When I setup a job to do continuous integration I've set the flag to true for the "Incremental build" option.
      I've then made a trigger in Clearcase to trigger the build when a user checks in an element.
      The trigger is nicely cached in Hudson and the job is started. The maven goals are "clean install".

      So far, so good. Until Hudson has to decide what module it should build. Or, in other words, what file was checked in in what module. Suppose one has 2 modules. Then if a file is checked in in the first module, only this module and all dependent modules should be build.

      In the log, I can see that the function "cleartool lshistory" is started and that the checked-in file is detected. Also the changelog.xml in the job folder has a reference to this file.

      After the lshistory has run and the view is updated (if it is a snaphot view), a java program is started with as argument hudson.maven.agent.Main and a few extra arguments and a classpath spec. I suppose this is the program that defines the specific pom of the module that the checked in file includes.

      But, and now it comes, no matter what file I check in, the maven command line has the root pom as argument after the -pl maven option. (if a incremental build is selected and detected, the maven parameters are changed to "-amd -pl").

      What could be the fault? May be I've overlooked something.
      If we can not build a "incremental build" then continiuous integration doesn't work at all.

      The current version I use is 1.368 but I have even updated to the latest Hudson version but the results were the same.

          [JENKINS-7835] Incremental build doesn't work in a maven2 aggregation project with Cleacase

          ecv added a comment -

          Hi kutzi,
          Thank you for investigating this issue.
          If this is the case (releated to another issue), how can I test the fix for this related issue. Is the fix already in a released version? Or can I replace a certain jar file in my Hudson installation with a newer one to check if this original issue is solved?
          Thanks

          ecv added a comment - Hi kutzi, Thank you for investigating this issue. If this is the case (releated to another issue), how can I test the fix for this related issue. Is the fix already in a released version? Or can I replace a certain jar file in my Hudson installation with a newer one to check if this original issue is solved? Thanks

          kutzi added a comment -

          Sorry, I should have provided more info.
          I suspect that this issue might have been introduced by the (supposed) fix for JENKINS-5357, because I run an earlier version of Hudson and incremental builds work fine.

          It was introduced in Hudson 1.378, but you reported thta the issue also appeared in 1.368, so I might be completely wrong here.

          kutzi added a comment - Sorry, I should have provided more info. I suspect that this issue might have been introduced by the (supposed) fix for JENKINS-5357 , because I run an earlier version of Hudson and incremental builds work fine. It was introduced in Hudson 1.378, but you reported thta the issue also appeared in 1.368, so I might be completely wrong here.

          ecv added a comment -

          OK. Thank you for the clarification.
          I've even made a project now without clearcase and a master pom in a root folder with 2 submodules each in a subfolder. This way, there are no <module/> specs in the master pom that have relative paths to the submodules and this even does not work. In fact, "incremental build" and "continuous integration" at all does not work. What a pitty because that the reason I used Hudson in the first place.

          Have a nice day

          ecv added a comment - OK. Thank you for the clarification. I've even made a project now without clearcase and a master pom in a root folder with 2 submodules each in a subfolder. This way, there are no <module/> specs in the master pom that have relative paths to the submodules and this even does not work. In fact, "incremental build" and "continuous integration" at all does not work. What a pitty because that the reason I used Hudson in the first place. Have a nice day

          ecv added a comment -

          Does anyone has a comment on this?
          This issue is about plain "incremental build" or "continuous integration". I can not imagine that nobody has a complaint about this. Or is it just me that has this issue.
          It has nothing to do with the SCM that one uses but only with the fact that when the "incremental build" checkbox is selected that it do not only building the modules that were changed but all the modules in a multi-module maven project. See previous comment from me...

          Thanks for the response.
          Eric

          ecv added a comment - Does anyone has a comment on this? This issue is about plain "incremental build" or "continuous integration". I can not imagine that nobody has a complaint about this. Or is it just me that has this issue. It has nothing to do with the SCM that one uses but only with the fact that when the "incremental build" checkbox is selected that it do not only building the modules that were changed but all the modules in a multi-module maven project. See previous comment from me... Thanks for the response. Eric

          banoss added a comment - - edited

          This seems to be a problem for Hudson on Windows but not for Hudson on Solaris.

          I've set up Hudson on Win and Solaris using the same ClearCase project and making a change to only 1 of 3 modules; Hudson builds all 3 modules on Windows, but only the changed module on Hudson on Solaris.

          Project structure is simple parent POM with 3 modules.

          Tested with Hudson v1.387

          In both Windows and Solaris, the SCM changes reported for the project are correct.

          banoss added a comment - - edited This seems to be a problem for Hudson on Windows but not for Hudson on Solaris. I've set up Hudson on Win and Solaris using the same ClearCase project and making a change to only 1 of 3 modules; Hudson builds all 3 modules on Windows, but only the changed module on Hudson on Solaris. Project structure is simple parent POM with 3 modules. Tested with Hudson v1.387 In both Windows and Solaris, the SCM changes reported for the project are correct.

          ecv added a comment -

          Hello banoss,
          Great that you could simulate my situation. Although It happens too with the "File system SCM" plugin (see my previous comments on this). It has probably nothing to do with the kind of SCM one uses.
          Good luck in hunting this issue.

          ecv added a comment - Hello banoss, Great that you could simulate my situation. Although It happens too with the "File system SCM" plugin (see my previous comments on this). It has probably nothing to do with the kind of SCM one uses. Good luck in hunting this issue.

          banoss added a comment -

          I agree its not an SCM issue. I suggest if you need this functionality run Hudson on Unix for now until this is resolved.

          banoss added a comment - I agree its not an SCM issue. I suggest if you need this functionality run Hudson on Unix for now until this is resolved.

          ecv added a comment -

          Don't have an Unix box. On the other hand, I need then to setup a Unix version of Clearcase on that box. I would take a lot of work to get around a problem of Hudson.
          What wonders me is that it seems that I'm the only one that is trying to setup Hudson as a "continious integration tool" on Windows. I didn't find this issue with other users.

          ecv added a comment - Don't have an Unix box. On the other hand, I need then to setup a Unix version of Clearcase on that box. I would take a lot of work to get around a problem of Hudson. What wonders me is that it seems that I'm the only one that is trying to setup Hudson as a "continious integration tool" on Windows. I didn't find this issue with other users.

          kutzi added a comment -

          ecv, sorry, but it's getting hard to get what the actual problem is now. Could you please clarify what's the current issue in the name of the issue. Also a minimal test project to reproduce the issue would dramatically improve the chance that this issue is getting fixed.

          kutzi added a comment - ecv, sorry, but it's getting hard to get what the actual problem is now. Could you please clarify what's the current issue in the name of the issue. Also a minimal test project to reproduce the issue would dramatically improve the chance that this issue is getting fixed.

          ecv added a comment -

          Dear kutzi,
          I'm using now a later version of Jenkins (1.407) and it seems to work to get incremental builds from it. For my part, you can close this issue because it works with this version (and probably later versions).
          Thank you for your concern.

          ecv added a comment - Dear kutzi, I'm using now a later version of Jenkins (1.407) and it seems to work to get incremental builds from it. For my part, you can close this issue because it works with this version (and probably later versions). Thank you for your concern.

            Unassigned Unassigned
            ecv ecv
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: