Maven Multi Module Configuration du projet avec diverses dépendances différentes

Question

Permettez-moi de dire cela en premier: je suis tout neuf à Maven.Cela dit que j'ai cherché autour, mais n'ai pas trouvé de réponses à la question suivante.J'ai trouvé des réponses à des questions similaires, mais pas ce scénario.Ou peut-être que j'ai mal compris les réponses et cela peut être résolu simplement sur une configuration multi-module.

J'aurais la hiérarchie de dépendance suivante:

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

J'aimerais faire fonctionner cela afin que les modifications ne produisent que de nouvelles versions de tous les modules / applications "en amont".Est-ce en effet un cas simple de configuration multicouille Maven Maven ou dois-je faire autre chose?

Answer 1

Si vous voulez que la libération d'un composant produise une nouvelle version de chaque projet, utilisez simplement Maven-Living-plugin : http://maven.apache.org/maven-release/maven-release-plugin/ .

Documentation

Selon Doc, ce serait:

• Vérifiez qu'il n'y a pas de changements non engagés dans les sources
• Vérifiez qu'il n'y a pas de dépendances instantanées
• Modifiez la version dans les POMS de X-Snapshot en une nouvelle version (vous serez invitée aux versions à utiliser)
• Transformez les informations SCM dans le POM pour inclure la destination finale de la balise
• Exécutez les tests de projet contre les POMD modifiés pour confirmer que tout est en état de fonctionnement
• commettre les pompons modifiés
• Tag Le code dans le SCM avec un nom de version (cela sera invitée à)
• Bump La version dans les POMS à une nouvelle valeur Y-Snapshot (ces valeurs seront également invitées)
• commettre les pompons modifiés

En raison de la structure MAVEN Multi Module, elles sont liées ensemble et chaque projet serait heurté dans une nouvelle version.

Dans quelques mots, cela:

• Déplacer la version 1.0-Snapshot -> 1.1-Snapshot
• TAG 1.0
• génère 1.0.jar (ou chose de guerre ou autre chose)

Utilisation du plugin

En supposant que SCM soit correctement défini, et la gestion du référentiel et de la distribution configuré, il suffit d'ajouter ces lignes

<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>

et appelez

mvn release:prepare
mvn release:perform

Héritage vs Dépendance

Vous pouvez envisager les deux différents approches Maven:

• héritage, qui signifie parent et modules multi / sub / sous-modules
• Agrégation, en d'autres termes: utilisation de dépendances

Dans un projet multi-maven, tous vos modules, y compris les parents, partagent le même cycle de vie. Libérer l'un implique tout libérant, et donc, libérant un seul n'est pas un sens.

Dans votre cas, vous ne pouvez pas modifier l'application 1 à 3 Whoutout impact sur l'application 4. Si l'application 4 dépend de l'application 1, évidemment, l'application 1 ne peut pas dépendre de l'application 4 (les références circulaires ne sont pas autorisées).

Donc, vous voulez isoler l'APP4 et l'APP1 à 3 Lifecycles, vous ne devez pas utiliser plusieurs modèles, mais il suffit de partager un projet parent, ou d'une hiérarchie de POM comme entreprise> Projet principal> Sous-projet (pas sous-module). Après cela, déclarez simplement une dépendance entre l'application 4 et l'application 1. (... dans l'App4 pom.xml)

Juste une autre pensée: le nom de vos projets et de vos sous-modules semble étrange. La hiérarchie "classique" est souvent (compte tenu du domaine d'objet multi-affaires pour un grand projet):

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

Donc, la base de données est rarement au sommet de la hiérarchie.