1

In maven multimodule project, there is a submodule that needs to inherit from external parent project. Therefore it cannot inherit from the parent module as other submodules, and those cannot inherit that external parent (so making the external project the parent of the entire hierarchy is not an option).

Is there a way to eliminate the duplication of properties between such module and the rest of the hierarchy?

parent pom.xml

    <properties>
        <foo>bar</foo>
    </properties>

    <modules>
        <module>child</module>
        <module>stepchild</module>
    </modules>

child pom.xml

    <parent>
        <groupId>my</groupId>
        <artifactId>parent</artifactId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>
    <description>foo can be used: ${foo}</description>

stepchild pom.xml

    <parent>
        <groupId>external</groupId>
        <artifactId>parent</artifactId>
        <version>35</version>
        <relativePath/>
    </parent>
    <description>foo does not get substituted: ${foo}</description>
Oliver Gondža
  • 3,386
  • 4
  • 29
  • 49
  • 1
    Based on the given stepchild you have a mixture of multi module build and an aggregator build cause your stepchild does not correctly use it's parent which is generally a bad idea..The question comes up: Why do you need a property of a different parent? Sounds like your parents have a design flaw... – khmarbaise Jan 21 '20 at 14:12
  • As a sidenote: there's a circular dependency between your parent pom and the child pom. This creates a monolith and may cause several problems, especially when targeting modern development techniques (CI and the likes). I suggest you separate the aggregation from the parent. – Amadán Jan 21 '20 at 14:14
  • @khmarbaise, The distinction you are pointing out - either have all sub-modules part of the hierarchy or none - is it documented somewhere? What are the implications of violating it exactly? The implementation is most certainly flawed (as it does not work), but is there a better one (that permit to share properties without inheriting entire build config)? – Oliver Gondža Jan 21 '20 at 14:39
  • @Amadán, I am not sure I see what circular dependency you mean. Also, what problem are you referring to? – Oliver Gondža Jan 21 '20 at 18:42
  • @OliverGondža I was assuming that child imports your parent pom. With the parent importing child as submodule, you'd have a circular dependency. This means there's no way to separate those modules which lets you end up with a big monolith. You might find it hard to get the submodules built independently by your CI server, thus causing longer than necessary build (+feedback) times for changes to individual submodules. Also if a change to one submodule breaks your build, you'll ultimately stop development on all other submodules as well, as the broken one prevents you from building the monolith. – Amadán Jan 22 '20 at 08:09
  • @Amadán, putting modules not inheriting from each other into a module hierarchy avoids all the advantages of doing so (inheritance) to begin with, especially if there is a requirement to build them independently. You are getting a monolith you are trying to avoid the day to check such projects (mind the plural) into a single code repository. It has nothing to do with maven multimodule project. – Oliver Gondža Feb 07 '20 at 09:53

1 Answers1

1

beside all problems found by other users in comments above, you can set properties using a reusable file 'my.properties' containing foo=bar

and adding to maven:

<build>    
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0-alpha-1</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
            <configuration>
              <files>
                <file>${basedir}/../project-parent/my.properties</file>
              </files>
            </configuration>
          </execution>
        </executions>
      </plugin>
   </plugins>
cedric.walter
  • 731
  • 6
  • 7