We use multiple svn repositories for different layers of our application, such that modules in layer 2 can depend on modules in layer 1, but not vice versa. Rather than defining a different build for each layer, all layers are grouped in one build, each repository in a separate jenkins module. So we have

/workspace/layer1 checkout of svn://whatever/layer1
/workspace/layer2 checkout of svn://whatever/layer2
/workspace/layer3 checkout of svn://whatever/layer3

We also have a profile (full) which connects all layers together so they can be built in one go (using -Pfull). So root pom.xml in layer 1 has profile which adds maven module ../layer2 and root pom.xml in layer 2 has profile which adds maven module ../layer3. We do this since we set build to poll svn and we want to make sure that a change in layer 1 will build dependent modules in layer 2 even if there are no svn changes in layer 2, which is achieved with the above setup.

We also use the incremental build feature, and this is where the bug is. basically, a change in either layer 2 or layer 3 causes the whole tree to be build because the paths are being incorrectly matched. This stems from 2 problems:

1. the subversion plugin reports paths in the changeset relative to the module folder rather than the workspace. this means that if there is a change in path a/b/file in layer2, the path would be reported as a/b/file rather than layer2/a/b/file. From this path it is not possible to determine in which layer the change occurred and this causes any change in layer2 or layer3 to match the root module of layer1 since that module's path (empty string since it is at the root) will match any path

2. the maven plugin assumes everything is relative to the root module, so a path for a module in layer2 will be ../layer2/whatever

I have fixed the above 2 problems and so far our build is behaving as expected. I am attaching 2 patches that address the above problems and do the following:

1. svn changeset paths are reported relative to the workspace
2. maven module paths are converted to workspace-relative paths when comparing with the changeset

NOTE that the above fix in the maven plugin assumes that an scm will report affected files relative to the workspace (which I'm assuming is how they should have behaved in the first place since the javadoc for ChangeLogSet.Entry.getAffectedPaths() states Returns a set of paths in the workspace that was affected by this change). This means that any other scm plugins (CVS, git?) would need to be patched in the same way. i.e. by reporting the affected paths relative to the workspace.