-
Bug
-
Resolution: Fixed
-
Critical
-
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.
- is related to
-
-
- Reopened
-
-
-
- Resolved
-
-
-
- Closed
-
[JENKINS-7835] Incremental build doesn't work in a maven2 aggregation project with Cleacase
ecv
created issue -
ecv
added a comment - 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.
ecv
added a comment - 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. 
kutzi
added a comment - Assigned to clearcase and maven2 component as it seems to be a problem in either of these.
kutzi
added a comment - Assigned to clearcase and maven2 component as it seems to be a problem in either of these. kutzi
made changes -
| Component/s | New: clearcase [ 15503 ] | |
| Component/s | New: maven2 [ 15487 ] | |
| Component/s | Original: core [ 15593 ] |
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
| Link |
New:
This issue is related to |
| Link | New: This issue is related to JENKINS-7651 [ JENKINS-7651 ] |
ecv
added a comment - 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
ecv
added a comment - 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 kutzi
added a comment - I guess this could be related to JENKINS-5357
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.