CODEWITHSUNDEEP
mavenmaven-3maven-release-pluginmulti-module
siki
siki

Reputation: 9487

Maven multi module project setup with various, different dependencies

Let me just say this first: I am brand new to Maven. That said I searched around but have not found answers to the following question. I found answers to similar questions, just not this scenario. Or maybe I just misunderstood the answers and this can be solved simply wiht a multi module setup.

I'd have the following dependency hierarchy:

database
|  |
|  +---core
|      |  |
|      |  +---business 
|      |        |
|      |        +------App1
|      |        |
|      |        +------App2
|      |
|      +---------------App3
|
+----------------------App4

I'd like to make it work so that changes only result in new releases of any "upstream" modules/Apps. Is this indeed a simple case of multi-module maven setup or do I need to do something else?

Upvotes: 1

Views: 514

Answers (1)

Jean-Rémy Revy
Jean-Rémy Revy

Reputation: 5677

If you want that releasing one component produce a new release of each project, just use : http://maven.apache.org/maven-release/maven-release-plugin/.

Documentation

As per doc, this would :

  • Check that there are no uncommitted changes in the sources
  • Check that there are no SNAPSHOT dependencies
  • Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
  • Transform the SCM information in the POM to include the final destination of the tag
  • Run the project tests against the modified POMs to confirm everything is in working order
  • Commit the modified POMs
  • Tag the code in the SCM with a version name (this will be prompted for)
  • Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
  • Commit the modified POMs

Because of the maven multi module structure, they are linked together, and each project would be bumped into a new release.

In a few words, this will :

  • move version 1.0-SNAPSHOT --> 1.1-SNAPSHOT
  • tag 1.0
  • generate 1.0.jar (ou war or anything else)

Plugin usage

Assuming that SCM is correctly defined, and repository and distribution management configured, just add these lines 

<project>
  [...]
  <build>
    [...]
    <plugins>
      [...]
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.4.2</version>
        <!-- optional, basic format is ${project.artifactId}-${project.version}.${project.type}-->
        <configuration>
          <tagNameFormat>v@{project.version}</tagNameFormat>
        </configuration>
      </plugin>
      [...]
    </plugins>
    [...]
  </build>
  [...]
</project>

And call 

mvn release:prepare
mvn release:perform

Inheritance vs Dependency

You may consider the two differents Maven approches :

  • inheritance, that means parent and multi/sub modules
  • aggregation, in other words : use of dependencies

In a multi-maven project, all your modules, including parent, share the same lifecycle. Releasing one imply releasing all, and so, releasing just one is a non sense.

In your case, you can't modify app 1 to 3 whithout impacting app 4. If App 4 depends App 1, obviously App 1 can't depends on App 4 (circular references are not allowed).

So, you want to isolate App4 and App1 to 3 lifecycles, you should not use multi-modules, but just share a parent project, or a hierachy of pom like corporate > main project > sub project (not submodule). After that, just declare a dependency between App 4 and App 1. (... into app4 pom.xml)

Just another thought : the name of your projects and submodules sounds strange. "Classical" hierarchy is often (considering multi business object domain for a large project): 

Main Project (sometimes EAR) --> POM 
|-- Business Object / DAO --> POM
|   |-- Domain 1 --> JAR
|   `-- Domain 2 --> JAR
|-- Core (depends on BO)  --> JAR
`-- IHM / Web App (depends on core)  --> WAR

So, database is rarely at the top of hierarchy.

Upvotes: 1

Related Questions