Maven2 + Subversion - Jenkins is building entire project instead of only changed modules

[Alec Disharoon]

I'm currently trialing Jenkins, and I'm attempting to have it build
individual modules whenever it determines that a module has been
changed in subversion. However, no matter what I try, it always
builds the entire project. Under "Source Code Management" on the
project configuration screen, I've configured the the subversion URL
and local file system path of each and every one of the many modules
in the project. When a module is changed in subversion, the poller
correctly detects it and starts a build. In the console, it correctly
lists which modules have been changed and which have not, but then
proceeds to build everything.

I haven't had much luck with the documentation or mailing lists - what
I've read implies there's some way to "enable" incremental builds, but
I haven't seen it. Can anyone help?

I'm running the following versions on a Ubuntu Server 11.04 system:

Jenkins - 1.426 - installed via the .deb
Maven plugin - 1.426
Subversion plugin - 1.31
Maven - 2.2.1
Subversion - 1.6.6

[Justin]

Hi,

Do you have a multi-module setup with the modules beside the parent
rather than being nested within it?

If so, this is the same problem that I raised a few weeks ago:
http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/e4edc4be77018031/599d6e7a8aef9e0a

There is an issue raised against it, it needs a few votes:
https://issues.jenkins-ci.org/browse/JENKINS-9139

I would love to get this resolved as well.

Regards,
Justin

[Alec Disharoon]

Justin -

I don't think the problem you mention applies to us exactly. The
project is one big checkout in the workspace, with the root pom.xml in
the top directory, 2 high level modules below that, and everything
else below one of those, like so:

/var/lib/jenkins/workspace/top_level_with_root_pom/
->/var/lib/jenkins/worksapce/top_level_with_root_pom/common_modules/
->->/var/lib/jenkins/worksapce/top_level_with_root_pom/common_modules/
various_modules
->/var/lib/jenkins/worksapce/top_level_with_root_pom/
standalone_modules/
->->/var/lib/jenkins/worksapce/top_level_with_root_pom/
standalone_modules/various_modules/

The subversion URL and the file system path of the local checkout of
each module, including the top level and the two high level
categories, has been entered into the project configuration under
"Source Code Management". Should I be doing that? It doesn't seem to
make a difference currently.

If one of the low level standalone modules, which other modules depend
on, but which do not depend on others themselves, gets changed in SVN,
I expect that only that module should get built. That's not
happening. It may be that the modules are more dependent on each
other than I realize - I'm not actually a developer on this project.
But I'm able to build them individually under "modules" in Jenkins. I
suspect that I'm missing some sort of necessary configuration to
enable incremental builds, but I don't know what.

Alec

On Aug 19, 9:02 am, Justin <justin.cros...@gmail.com> wrote:
> Hi,
>
> Do you have a multi-module setup with the modules beside the parent
> rather than being nested within it?
>

> If so, this is the same problem that I raised a few weeks ago:http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/e4e...

[Justin]

Hi Alec,

In the job Configuration, under Build -> Advanced, there is an
"Incremental build - only build changed modules" have you set that?

If all of your projects are under a top level pom, why do you need to
include the sub-folder svn locations? If you specify only the top
level, it will detect that something has changed, update the changes,
and detect what modules have changed this way.

HTH,
Justin

[Alec Disharoon]

Justin -

I don't know why I never saw that Advanced button. I checked all the
other ones. Thanks so much. As for why all the svn locations are
specified, it's because I was trying everything since I couldn't
figure out what I needed to do because I never saw that button for
some reason. I didn't think it made much sense.

Alec