Home/ Questions/Q 7076859
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T06:20:59+00:00

I have a Git repository that contains a bunch of top-level maven projects (each

  • 0

I have a Git repository that contains a bunch of top-level maven projects (each sits in their own sub-directory with a pom.xml). Top-level here means that these projects sit in subdirectory directly underneath the repository root. All of these projects should remain in the same Git repository.

repo
+--- projectA
    +--- pom.xml

+--- projectB
    +--- pom.xml

They can/should be built by independent jenkins jobs. So we have a job for projectA and one for projectB.

Formerly with Subversion I was able to set up a Jenkins job (for each project) that would checkout only the project source and run a Maven build from the pom.xml.

With the Git model (probably the same with all DVCS) this changes and I’m not sure what is best practice. There are a few options that I see and from which none I really like:

  1. Each Jenkins job is configured to clone/pull the full Git repo and
    refers to the /pom.xml for the Maven build. So the job
    has all the code but builds only a slice of it.
  2. Git offers Submodules (http://book.git-scm.com/5_submodules.html) which seem to
    be a bit tricky to handle (and can break easily)
  3. Create a maven parent (aggregator that contains all of the projects) project that
    triggers each projects build (having a single jenkins job). This pom.xml contains elements for projectA and projectB.

Do you see any more useful approach for this (very typical setup). What is your experience? Any best practices?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think you’re working against the grain here. If these projects are released as a versioned unit, you should indeed create a parent POM. But you should probably only have a single CI job. If you want that build to go quickly, you can configure it to only build modules which have changed since the last build (advanced button in Build section – “Incremental build – only build changed modules”). You can also tell Jenkins to “Execute concurrent builds if necessary” to test multiple commits at once.

    But I’m curious why you think you want multiple CI jobs? If you perceive that these two projects have different lifecycles, perhaps they should be versioned seperately and should therefore be in seperate git repositories. Don’t conserve git repositories, they are cheap. In fact, the more the merrier in almost every case.

    Usually, you want a given pom to produce a single artifact. Aggregator poms are useful for breaking up parts of a larger artifact into submodules, but only if those submodules aren’t released on their own.

    • 0