6

I have the following projects organized in a flat structured way:

parentProject
+-pom.xml

projectWeb <depends on libraryA and libraryB>
+-pom.xml

libraryA
+-pom.xml

libraryB
+-pom.xml

The pom.xml inside the parentProject has references to the other modules and its used for inheritance and dependencyManagement, here is a snippet: 

<project>
    ....
    <modules>
        <module>../projectWeb</module>
        <module>../libraryA</module>
        <module>../libraryB</module>
    </modules>
    <dependencyManagement>
    ...
    </dependencyManagement>
    <build>
    ...
    </build>
    ....
</project>

In Jenkins I have one maven job for each project, and it works fine when I build the parentProject, ie. builds every project referenced in the modules section. The problem that I have is when I commit to the SVN a change in libraryA, I would expect that after building libraryA, a rebuild to projectWeb to be launched, but that didn't happen. Anyone knows what am I doing wrong?

Thanks in advance.

EDIT

When I remove the modules section from parentProject\pom.xml, it works as espected, but I loose the aggregation advantage of having a parent pom.

Diego Sergnese
  • 340
  • 4
  • 12

2 Answers2

1

It looks like you're asking your parent POM to do two things:

  1. Set up dependency management stuff
  2. Aggregate your build

It's generally better if you split this out into two poms - a parent pom for #1 and an aggregate pom for #2. You'd then have something like..

[root dir] aggregate pom.xml
+ /parent 
+ /web
+ /libA
+ /libB

See this answer for more details: https://stackoverflow.com/a/3301162/211993

You'd then configure Jenkins to check out the root dir and run "mvn clean install"

Community
  • 1
  • 1
dan
  • 164
  • 8
  • 2
    Can you please elaborate on why "It's generally better if you split..."? I'm not saying it's not but I don't understand why it is better. Unfortunately I did not understand it from the answer you've linked to. Thanks! – Ittai Nov 11 '12 at 13:31
  • 1
    So, initially, it just helps with separation of concerns - the aggregator is responsible for the order in which modules are built, the parent is responsible dependency versions and things like scm connection details. – dan Jan 25 '13 at 16:51
  • 1
    Also, I've seen examples where people have broken down their parent pom into common parts, which then become the parents for other parent poms. Say, for example, you've a couple of projects that use Hibernate, you can pull that bunch of versioning into a hibernate parent pom, and then use that as a "super parent" (as it were, I just made that phrase up) giving you consistent versions of the hibernate library across multiple projects that aren't otherwise linked. But make sure you actually want that shared approach; you're coupling multiple projects together which might not be desirable. – dan Jan 25 '13 at 16:57
  • 1
    Or, you might break is into a bunch of super-parents that never get shared, you just do it for readability. To be honest, I've never taken it further than the single parent and single aggregator, but I do find that's a lot cleaner than the parent and aggregator in one. – dan Jan 25 '13 at 16:58
0

This should be configured in jenkins job. See "libraryA job"/"Configuration"/"Build Triggers"/"Build after other projects are built"

alexei-grigoriev
  • 189
  • 11
  • Thanks for the reply, but as I put in the edited question, If I remove the modules from the parent pom, the builds are triggered as expected, ie, if I build `libraryA` then `proyectWeb` is builded automatically, without the configuration you mentioned. – Diego Sergnese Sep 27 '12 at 17:31