Maven - Inclure différents fichiers au moment de la construction

Question

J'ai dix fichiers WAR, qui ont tous un code presque identique et le balisage. Les seules différences se situent dans les images, CSS et messages. Je frappe sur le concept de profils mais je ne l'ai pas tout à fait groked encore et je ne suis pas sûr si cela peut gérer ce que je besoin de le faire.

En fait, je veux un projet de base avec des profils différents pour les 10 différents WARs. A chaque fois qu'une construction commence avec un profil donné, il va à un dépôt (soit local ou de mon organisation) et récupère les CSS, les images et les fichiers messages et les place au bon endroit avant de terminer le processus. Je ne peux pas imaginer cela est très différent que de sortir et récupérer un fichier JAR et de le mettre dans le répertoire lib WEB-INF.

Je suis sûr que ce n'est pas trop loin dans le champ gauche et je veux rester au sweet spot de Maven autant que possible. Toute aide serait appréciée!

Answer 1

Si vous voulez garder chacun des projets distincts, vous pouvez donner à chaque projet sa propre pom.xml. Dans chaque projet enfant pom, ajouter une dépendance pour le projet parent. Cela entraînera la construction à faire une « superposition » dans lequel les fichiers du projet d'enfant sont ajoutés à (ou écraser des fichiers dans le) projet parent. la dépendance à l'exemple de projet enfant:

<dependency>
   <groupId>com.example.app</groupId>
   <artifactId>example</artifactId>
   <version>1.0.0</version>
   <type>war</type>
</dependency>

Answer 2

Je peux penser à des solutions basées sur les profils, le plug-in de guerre Maven et le filtrage comme décrit dans Ajout et filtrage des ressources Web externe .

Mais cela ne répond pas à la comment utiliser les ressources web comme « dépendances » partie de votre question.

Pour cela, le

Les profils devraient être un bon moyen pour cela. Selon les informations Maven construire le profil docs cela ne devrait pas fonctionner. Plus précisément, ils disent

build as specified inside of a profile is not a full implementation of the traditional
build POM element. This build is really another class in the model - from which the POM
build is derived - and only allows the plugins and pluginManagement subelements when 
defined here. This sidesteps any issues with secondary validation after the pom.xml is 
parsed in this case.

Mais je viens de tester et il inclus les ressources appropriées en incluant un élément de construction avec une définition de ressources à l'intérieur.

Dans votre pom, vous voulez inclure un profil pour chacun de vos webapps. Par exemple, dans mon test, je l'ai fait ce qui suit:

<profile>
    <id>abc</id>
    <activation>
        <activeByDefault>false</activeByDefault>
    </activation>
    <build>
        <resources>
            <resource>
                <directory>abc</directory>
                <includes>
                    <include>**/*</include>
                </includes>
            </resource>
        </resources>
    </build>
</profile>
<profile>
    <id>xyz</id>
    <activation>
        <activeByDefault>false</activeByDefault>
    </activation>
    <build>
        <resources>
            <resource>
                <directory>xyz</directory>
                <includes>
                    <include>**/*</include>
                </includes>
            </resource>
        </resources>
    </build>
</profile>

Alors, j'avais un répertoire contenant un abc abc.properties de fichier, et un autre xyz avec un fichier xyz.properties correspondant.

Pour toutes les ressources partagées, vous auriez un élément qui a aussi un élément qui inclut tous ceux que vous voulez utiliser dans tous les webapp.

Enfin, lorsque vous vous construisez spécifier le profil de la webapp que vous souhaitez construire, par exemple     mvn -P abc clean install

Une question BIG vous pouvez avoir avec cette approche est que chaque artefact construit aura le même nom, et on écrase l'autre dans votre dépôt local.

Oui, je réponds à cette question deux fois parce que chaque approche est sensiblement différente.

Plutôt que d'avoir un seul pom.xml qui a un profil pour chacun de vos fichiers de guerre, vous pourriez avoir un projet qui contient 11 modules. Un module Maven qui a tout de la source commune, et chacun de vos dossiers de guerre serait une autre, module adjacent qui a seulement les fichiers qui lui sont propres. Tous ces modules seraient sous une pom racine.

Dans le pom pour chacun de vos modules de guerre, alors vous configurer les ressources et sourceDirectory dans votre configuration de construction pour pointer vers ../base-project/src/main/resources et ../base-project/src/ main / java respectivement.

La configuration maven-plugin-guerre alors la configuration de webResources pour pointer vers ../base-project/src/main/webapp et à vos ressources spécifiques à la guerre ./src/main/webapp.

Avec cette solution, vous auriez différents artefacts Maven pour chacun de vos dossiers de guerre et ils pourraient tous coexister au sein de votre référentiel .m2 sans aucun problème.

Vous pouvez toujours utiliser les ressources-maven-plugin-distance. Vous créer submodule construit pour chacun de vos ensembles de ressources, par exemple la création d'un appelé « my-projet-ressources customer1.jar. Ce sont comme tout autre artefact Maven et peuvent être mis dans vos opérations de pension locaux ou distants.

Dans votre guerre, vous auriez construire la configuration du plugin ci-dessous qui va exploser le contenu des pots de regroupement de ressources spécifiés dans votre répertoire cible et inclure ensuite les dans votre dossier de guerre. Cette configuration peut être contrôlée par eaily profils qui définissent une propriété « profilename » pour sélectionner la ressource nécessaire.

<plugin>
    <artifactId>maven-remote-resources-plugin</artifactId>
    <executions>
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>process</goal>
        </goals>
        <configuration>
          <resourceBundles>
            <resourceBundle>org.mygroup:my-project-resources-${profilename}:${pom.version}</resourceBundle>
          </resourceBundles>
        </configuration>
      </execution>
    </executions>
  </plugin>

Une mise en garde (son un petit) est d'être prudent lorsque vous spécifiez les versions de ressources si vous utilisez le plugin de libération Maven. Si vos ressources et le fichier de guerre partagent une version commune, vous aurez envie d'utiliser la propriété $ {} de pom.version dans le plug-in. Ensuite, lorsque le plugin version met à jour votre version de parent à 1.1 le plug-in doit refléter cette utilisation automatiquement la version 1.1 du faisceau de ressources. Si vous n'êtes pas libérer les faisceaux de ressources au même rythme que la guerre, alors vous serez bien préciser la version explicitement.

HTH

ste

Answer 3

Answer 4

Answer 5

Answer 6

Answer 7

Les profils devraient être un bon moyen pour cela. Selon les informations

Answer 8

Oui, je réponds à cette question deux fois parce que chaque approche est sensiblement différente.

Plutôt que d'avoir un seul pom.xml qui a un profil pour chacun de vos fichiers de guerre, vous pourriez avoir un projet qui contient 11 modules. Un module Maven qui a tout de la source commune, et chacun de vos dossiers de guerre serait une autre, module adjacent qui a seulement les fichiers qui lui sont propres. Tous ces modules seraient sous une pom racine.

Dans le pom pour chacun de vos modules de guerre, alors vous configurer les ressources et sourceDirectory dans votre configuration de construction pour pointer vers ../base-project/src/main/resources et ../base-project/src/ main / java respectivement.

La configuration maven-plugin-guerre alors la configuration de webResources pour pointer vers ../base-project/src/main/webapp et à vos ressources spécifiques à la guerre ./src/main/webapp.

Avec cette solution, vous auriez différents artefacts Maven pour chacun de vos dossiers de guerre et ils pourraient tous coexister au sein de votre référentiel .m2 sans aucun problème.

Answer 9

Vous pouvez toujours utiliser les ressources-maven-plugin-distance. Vous créer submodule construit pour chacun de vos ensembles de ressources, par exemple la création d'un appelé « my-projet-ressources customer1.jar. Ce sont comme tout autre artefact Maven et peuvent être mis dans vos opérations de pension locaux ou distants.

Dans votre guerre, vous auriez construire la configuration du plugin ci-dessous qui va exploser le contenu des pots de regroupement de ressources spécifiés dans votre répertoire cible et inclure ensuite les dans votre dossier de guerre. Cette configuration peut être contrôlée par eaily profils qui définissent une propriété « profilename » pour sélectionner la ressource nécessaire.

<plugin>
    <artifactId>maven-remote-resources-plugin</artifactId>
    <executions>
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>process</goal>
        </goals>
        <configuration>
          <resourceBundles>
            <resourceBundle>org.mygroup:my-project-resources-${profilename}:${pom.version}</resourceBundle>
          </resourceBundles>
        </configuration>
      </execution>
    </executions>
  </plugin>

Une mise en garde (son un petit) est d'être prudent lorsque vous spécifiez les versions de ressources si vous utilisez le plugin de libération Maven. Si vos ressources et le fichier de guerre partagent une version commune, vous aurez envie d'utiliser la propriété $ {} de pom.version dans le plug-in. Ensuite, lorsque le plugin version met à jour votre version de parent à 1.1 le plug-in doit refléter cette utilisation automatiquement la version 1.1 du faisceau de ressources. Si vous n'êtes pas libérer les faisceaux de ressources au même rythme que la guerre, alors vous serez bien préciser la version explicitement.

HTH

ste