RTC SCM does not allow sandboxes to be nested within one another.

The error indicates that the RTC repository workspace has been loaded in one directory (workspace) and the second build is trying to create a sandbox (workspace/jdk/IBM-JDK-7) within the original sandbox when doing the load. The directories are:
/data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace
/data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/jdk/IBM-JDK-7

I am not sure if it is really your intent to have them nested, but its not supported.

One option is in the Jenkins Job(s) under Advanced Project Options, check off "Use custom workspace" and specify a directory that will be a sibling of the other builds.

Another option is to create a Build definition and on the Jazz Source Control tab specify the Load directory (right now its a relative path from the Jenkins Job's workspace). You might need a couple of build definitions, one for each job.

I will look at your suggestions - thanks.

However it seems to me that the problem is that the RTC plugin is doing a checkout in the root project and it is this checkout that is causing the problem? If you look at the trace that I sent you will see that the "configured sub-projects" are checking out the code correctly in a sub-project (but using the same workspace because that is how multi-configuration projects are defined in Jenkins). The nesting comes from the initial checkout in the root project by the RTC plugin which is superflous as we are not going to do any builds in the root project?

Can you confirm that the multi-configuration project does work with the RTC plugin and if yes could you provide me with an example so that I can see what I am doing wrong in my configuration?

Thanks again for your help.

I see your point. I have been looking into this more. I am not sure how you configure a matrix build not to load in the root project, just in the sub project. Can you help me understand your matrix build configuration (so I can sort of replicate)?

What I am trying to do is fairly simple. I have a Jenkins job that builds a maven project using the maven goals "clean deploy". As part of these goals the unit tests are being run and reported by Jenkins (and/or RTC now that you have added the RTC build support). What I wanted to do with the multi-configuration project is run the maven project with the goals "clean test" but with different JDK's as we have seen some problems moving between JDK6 and JDK 7. Hence I created several JDK's in my Jenkins configuration and then I created a multi-configuration project and selected my different JDK's.

I've replicated the problem and my suggestion regarding the build definition is not likely to work. I have though figured out how to configure the project so that it will load into non-nested directories.

In the section "Advanced Project Options" click the advanced settings button

Check the box "Use custom workspace" it will expand a section to supply workspace paths for the main build and the sub-builds.

In the "Directory" textbox, put an absolute path and a directory in which to load for the main build.
ie. /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob

In the "Directory for sub-builds" textbox, put the same absolute path minus the directory for the main build followed by /${JOB_NAME}
i.e. /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/${JOB_NAME}

The JOB_NAME is a variable populated by Jenkins, there may be nicer variables, but I haven't found them. The other key point is to use an absolute path for each directory. The use of the variable will result in each of the sub jobs having their own directory.

This looks like it will work - it is a bit cumbersome though and will need to be done by hand for any multi-configuration project that uses RTC. Are you planning a solution in the RTC plugin to prevent a checkout in the main job or some other solution that does not require this manual fix?

I tried this and in fact it does not seem to work?

Building on master in workspace /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob/jobs/RunAsfTests10/workspace/RunAsfTests10/jdk=IBM-JDK-7
RTC : checkout...
RTC Checkout : Source control setup
RTC Checkout : Accepting changes into workspace "JenkinsRunAsfTests10" ...
FATAL: RTC : checkout failure: Cannot create sandbox at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob/jobs/RunAsfTests10/workspace/RunAsfTests10/jdk=IBM-JDK-7 because one already exists at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob
com.ibm.team.filesystem.client.FileSystemStatusException: Status ERROR: com.ibm.team.filesystem.client code=0 Cannot create sandbox at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob/jobs/RunAsfTests10/workspace/RunAsfTests10/jdk=IBM-JDK-7 because one already exists at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob null
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:309)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:1)
at com.ibm.team.filesystem.client.internal.SharingManager.register(SharingManager.java:1002)
at com.ibm.team.build.internal.hjplugin.rtc.RepositoryConnection.checkout(RepositoryConnection.java:363)
at com.ibm.team.build.internal.hjplugin.rtc.RTCFacade.checkout(RTCFacade.java:387)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.ibm.team.build.internal.hjplugin.RTCFacadeFactory$RTCFacadeWrapper.invoke(RTCFacadeFactory.java:92)
at com.ibm.team.build.internal.hjplugin.RTCCheckoutTask.invoke(RTCCheckoutTask.java:107)
at com.ibm.team.build.internal.hjplugin.RTCCheckoutTask.invoke(RTCCheckoutTask.java:31)
at hudson.FilePath.act(FilePath.java:906)

As you can see the 2 checkout directories are adjacent and not nested but it still complains about the sandbox (maybe because they are both using the same repository workspace)?

Actually the 2 directories are nested. The paths that are given for "Directory" and the "Directory for sub builds" must be absolute.

I see a similar problem. I tried the workaround you suggested above but it won't work for a master slave setup (workspaces are in different locations). Therefore, I cannot hard-code the directories and I found that ${WORKSPACE} is not substituted at all.

Any hints?