Home/ Questions/Q 7624229
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T04:54:29+00:00

Currently, I have the following structure for my project Foo : foo-parent +- pom.xml

  • 0

Currently, I have the following structure for my project Foo:

foo-parent
  +- pom.xml

project-foo
  +- pom.xml
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

In foo-parent, there is a pom.xml that defines all the generic configuration for my project (basic dependencies, plugins management, etc.).
The externalization of the parent helps me to have a stable parent configuration (which is not the case if the parent is the root pom.xml, which is also used for aggregating all modules).

The project-foo/pom.xml is only here to aggregate all the modules, and does not define any parent…

Now, I am modifying my project to use the Maven release plugin. Thus, I need to configure the <scm> information.
But where to put this information, since it depends on the branch where the code is located (i.e. the value of <scm> is different for the code in the trunk than in branch-X, or branch-Y).

  • Solution #1 Define the <scm> in the foo-parent project. This way, each module will have this information available. However, I will have several version of foo-parent project, one per branch. It will make the versioning of this parent quite harder…
  • Solution #2 Define the <scm> in the foo-parent project, but add a parameter inside (such as <scm>scm:svn:http://server/foo/${svn.branch}</scm>). However, this will just move the problem: where do I define the svn.branch property?
  • Solution #3 Define the <scm> in the project-foo/pom.xml, which will now have the foo-parent as parent, and change the <parent> of all sub-modules to point to project-foo/pom.xml (i.e. foo-parent > foo-root > module-X).
  • Solution #4 Define the <scm> (or svn.tag property) in each module. Don’t really like that…
  • Solution #5 Any other idea?

My point of view is to use the solution #3, but what are your feelings about that?

Thanks.

Edit (regarding khmarbaise answer)

The project foo-parent is in reality in a sub-directory of project-foo, but is not aggregated by project-foo/pom.xml file. I said that I “externalized” it just to show that it is separated from the rest of the modules. The main interest of that is to try to keep the parent as stable as possible, and that’s why I tried to separate the parent pom from the aggregation pom.

However, as I use extensively the Maven release plugin (not on that project, but on others projects), I think it’s better to not continue on this track, and merge all the foo-parent/pom.xml in the project-foo/pom.xml. This will ease the management of my project.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you like to use multimodules in maven you have to follow some best-practices which means first to have the parent into your structure and not outside. This means:

    project-foo
  +- pom.xml (This is your parent for the module-1 etc.)
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

    What is possible to deviate from that is to create a new folder:

    project-foo
  +- pom.xml 
  +- project-parent (pom.xml)
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

    But than you have to define the parent a little bit strange for module-1:

      <parent>
    <groupId>..</groupId>
    <artifactId>..<artifactId>
    <version>..</version>
    <relativePath>../project-parent/<relativePath>
  </parent>

    which i wouldn’t recommend cause it produces more configuration than needed…

    If you use the “default” which is the best-practice:

    project-foo
  +- pom.xml (This is your parent for the module-1 etc.)
  +- module-1
  |    +- pom.xml
  |    +- ...
  +- module-2
  |    +- pom.xml
  |    +- ...
  +- ...

    in your module-1 it looks like the following:

      <parent>
    <groupId>..</groupId>
    <artifactId>..<artifactId>
    <version>..</version>
  </parent>

    and in your parent (in this case).

    project-foo
  +- pom.xml (This is your parent for the module-1 etc.)

    you have to define the modules you are using:

    <modules>
  <module>module-1</module>
  <module>module-2</module>
  ..
</modules>

    Apart from that you should also define your dependencyManagement and pluginManagement into that pom.

    If you like to have a complete separate parent pom you have to define a separate project which contains the pom plus the scm configuration for that pom only and do a real release of that pom (like an jar artifact except that it is a pom) and of course a version which you can use in your project as parent.

    Coming to the point of the SCM area: The only location for such kind of information within a multimodule build is in the project-foo/pom.xml:

    project-foo
  +- pom.xml (This is your parent for the module-1 etc.)

    Nowhere else will be the definition of the SCM never in the modules! Furthermore never use properties to define the scm-area just use the information you need:

    scm:svn:scm:svn:http:///project/trunk/
    scm:svn:http:///project/trunk/
    scm:svn:http:///project/trunk/

    If you are woring about the problem using branches etc. you can handle that via the maven-release-plugin which gives you the possibility to create a branch via:

    mvn release:branch

    Based on that and during the release process the URL for the SCM area will changed appropriately. So you don’t need to worry about them (Never use properties for them, cause it won’t work!)

    You also need to configure the distributionManagement area to define where to put SNAPSHOT and released version of your artifacts (I hope you are using a Repository Manager like Nexus, Artifactory or Archiva?).

    I can recommend to read the Sonatype Book on multi-module builds etc.

    • 0