I've got a similar concern I'm trying to nail down the behaviour still. I'm using Hudson v1.377 and CC SCM plugin v1.2.1 with Base ClearCase, no UCM.

Which version of the CC SCM plugin are you on?

I do not see quite the behaviour you describe with the root pom after the -pl. I have examples where it seems correct with my stack.

Well, it is not version dependent I believe.
I've tested it out with a Hudson version 1.368 and a CC Plugin 1.3.1 but also with a Hudson 1.380 and the same 1.3.1 Clearcase Plugin.

A simple example could be: a root pom in a root directory that specifies 2 modules in 2 poms that are in 2 subfolders. Let say module_A and module_B. If one changes a file in module_A the result of the "cleartool lshistory" is a specification of a file in module_A. One should expect that maven starts with as parameter "-pl module_A" but his is not the case. The pom spec. after the -pl command is the pom in the root folder.

I hope this helps more.

Assigned to clearcase and maven2 component as it seems to be a problem in either of these.

Adding links to these issues since I believe this is the same root cause : getModuleRoot doesn't work properly when view path contains build-scoped variables

I did another test but now without using the ClearCase plug-in.
I referred to the original view\vob combination with the "File system SCM" plug-in as if it was a flat file system. Guess what, I have the same results. So the bug is not related to ClearCase.

What I did: I downloaded the File System SCM, made a copy of the original job and changed the SCM from ClearCase to File System. I referred to the path of the view\vob of the original job and build the job. At first it copied the files from ClearCase to the workspace and it checked what files were new (all of them of course were new). It builds the job with maven2 and had the -pl option in its command line. The modules that were referred after the -pl option were all of the modules (true, because all files were new in the workspace).
I then checked out one of the files of one module in ClearCase and checked it back in. After that, it had a later modification date as it had before this operation. I than build the job again and it found the touched file in the one module. Despite this, it builded the complete project with all modules in it.

Hope this helps and remark that in has nothing to with the ClearCase SCM.

Greetings,
Eric

I guess this could be related to JENKINS-5357

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

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.

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

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

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.

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

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, 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.

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.