Maven: personnaliser le fichier web.xml du projet d'application Web

Question

J'ai une application web de projet Maven, et je veux personnaliser la web.xml fichier en fonction du Profil, qui est en cours d'exécution. Je suis en utilisant le Maven-Guerre-plugin, ce qui me permet de définir une "ressources" répertoire où les fichiers peuvent être filtrés. Cependant, le filtrage seul n'est pas suffisant pour moi.

Plus en détail, je veux inclure (ou d'exclure) l'ensemble de la section sur la sécurité, selon le profil que j'ai un en cours d'exécution. C'est la partie:

....
....

<security-constraint>

    <web-resource-collection>
        <web-resource-name>protected</web-resource-name>
        <url-pattern>/pages/*.xhtml</url-pattern>
        <url-pattern>/pages/*.jsp</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>

    </security-constraint>
        <login-config>
        <auth-method>${web.modules.auth.type}</auth-method>
        <realm-name>MyRealm</realm-name>
    </login-config>

<security-constraint>

....
....

Si cela n'est pas fait facilement, il est un moyen d'avoir les deux web.xml de fichiers et de sélectionner le plus approprié en fonction du profil?

Answer 1

est-il possible d'avoir les deux web.xml de fichiers et de sélectionner le plus approprié en fonction du profil?

Oui, au sein de chaque profil, vous pouvez ajouter une configuration de l' maven-war-plugin et de configurer chaque point à un autre web.xml.

<profiles>
    <profile>
        <id>profile1</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-war-plugin</artifactId>
                    <configuration>
                        <webXml>/path/to/webXml1</webXml>
                    </configuration>
                </plugin>
                 ...

Comme une alternative à avoir à spécifier l' maven-war-plugin configuration de chaque profil, vous pouvez fournir une configuration par défaut dans la section principale de la POM et puis il suffit de le remplacer pour des profils spécifiques.

Ou, pour être encore plus simple, le principal <build><plugins> de votre POM, utiliser une propriété pour se référer à l' webXml d'attribut et puis il suffit de changer la valeur dans les différents profils

<properties>
    <webXmlPath>path/to/default/webXml</webXmlPath>
</properties>
<profiles>
    <profile>
        <id>profile1</id>
        <properties>
            <webXmlPath>path/to/custom/webXml</webXmlPath>
        </properties>
    </profile>
</profiles>
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <configuration>
                <webXml>${webXmlPath}</webXml>
            </configuration>
        </plugin>
        ...

Answer 2

Il y a une troisième, le compromis, l'option que j'ai mis en place mon projet. Il conserve tout dans un seul web.xml tout en continuant à faire tous les deux et la pom.xml lisibles. Dans mon cas, j'ai eu un besoin, parfois, de sécurité et n'ont parfois pas de sécurité, en fonction de l'environnement.

Donc, ce que j'ai fait:

Dans le pom.xml, définir deux profils (ou cependant beaucoup vous avez besoin). Dans les profils, notamment deux propriétés. Lorsque vous voulez de la sécurité, de les laisser vides, comme ceci:

<enable.security.start></enable.security.start>
<enable.security.end></enable.security.end>

Lorsque vous souhaitez exclure de la sécurité, de les définir comme suit:

<enable.security.start>&lt;!--</enable.security.start>
<enable.security.end>--&gt;</enable.security.end>

Ensuite, vous avez un seul web.xml fichier avec le texte suivant:

${enable.security.start}
<security-constraint>
  ...
  // all of the XML that you need, in a completely readable format
  ...
</login-config>  
${enable.security.end}

L'pom.xml maven-guerre-plugin doit être configuré pour utiliser le filtrage. Le mien ressemble à ça:

   <configuration>
      <webResources>
        <resource>
          <filtering>true</filtering>
          <directory>src/main/webapp</directory>
          <includes>
            <include>**/web.xml</include>
          </includes>
        </resource>
      </webResources>
      <warSourceDirectory>src/main/webapp</warSourceDirectory>
      <webXml>src/main/webapp/WEB-INF/web.xml</webXml>
      ...

Donc, fondamentalement, lorsque vous sélectionnez le profil de la sécurité, vous obtenez deux CRLF supplémentaire dans votre web.xml. Lorsque vous sélectionnez le profil à ne PAS inclure de sécurité, le document XML est tous encore dans la web.xml mais il est commenté, donc ils sont ignorés. J'aime cela parce que vous n'avez pas à vous soucier de garder plusieurs fichiers dans la synchronisation, mais le XML est encore lisible (et c'est dans la web.xml fichier où les gens seraient naturellement chercher).

Answer 3

Commentaire à la réponse de Chris Clark . Vous pouvez inverser - en développement, vous ne voulez donc pas avoir de contrainte (sécurité ou jndi, autre)

 <!-- ${enable.security.end}
<security-constraint>
    ...
</security-constraint>


${enable.security.start} -->
 

Donc, en développement, vous avez commenté la section. Mais en production, il sera traduit (avec le profil maven):

 <!-- -->
<security-constraint>
    ...
</security-constraint>


<!-- -->
 

et la section commentée sera visible.

Answer 4

"matt b" a déjà posté la réponse qui est la plus maven façon de faire. C'est la façon dont je le recommanderais de faire 99% du temps.

Cependant, de temps en temps, votre fichier de configuration peut être assez compliqué, et il n'a pas beaucoup de sens pour dupliquer l'intégralité du fichier pour chaque environnement, lorsque l'un XML strophe diffère. Dans ces cas, vous pouvez les abus de la propriété de filtrage pour atteindre votre objectif.

Avertissement, un très duct-tape-y, suit, et ne sera pas pour les faibles de cœur:

Dans votre pom.xml:

Attention StackOverflow Éditeurs!!!! L'entité html échapper est une partie de la solution. La solution ne fonctionnera PAS si vous le remplacer tous avec plus-et moins-que les signes. Merci de laisser la réponse est...

<properties>
    <test.security.config>
        &lt;security-constraint&gt;
            &lt;web-resource-collection&gt;
                &lt;web-resource-name&gt;protected&lt;/web-resource-name&gt;
                &lt;url-pattern&gt;/pages/*.xhtml&lt;/url-pattern&gt;
                &lt;url-pattern&gt;/pages/*.jsp&lt;/url-pattern&gt;
            &lt;/web-resource-collection&gt;

            &lt;auth-constraint&gt;
                &lt;role-name&gt;*&lt;/role-name&gt;
            &lt;/auth-constraint&gt;

            &lt;/security-constraint&gt;
                &lt;login-config&gt;
                &lt;auth-method&gt;${web.modules.auth.type}&lt;/auth-method&gt;
                &lt;realm-name&gt;MyRealm&lt;/realm-name&gt;
            &lt;/login-config&gt;

        &lt;security-constraint&gt;
    </test.security.config>
</properties>

dans votre web.xml

....
${test.security.config}
....

Car inexistante propriétés évaluer à une chaîne vide, vos configurations qui n'ont pas cette propriété ou la propriété est vide balise xml) permettra d'évaluer à une ligne vide ici.

C'est moche, et le xml est difficile de modifier ce formulaire. Toutefois, si votre web.xml est complexe et vous poser un plus grand risque de 4-5 exemplaires de la web.xml sortir de la synchronisation, ce peut être une approche qui va travailler pour vous.

Answer 5

Une nouvelle configuration a été ajoutée à maven-war-plugin dans la version 2.1-alpha-2. Son nom est filteringDeploymentDescriptors et il fait exactement ce que vous voulez.

Cela marche:

 <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
    </configuration>
</plugin>
 

Et cela fonctionne aussi:

 <properties>
    <maven.war.filteringDeploymentDescriptors>true</maven.war.filteringDeploymentDescriptors>
</properties>
 

Plus d'informations sont disponibles dans la documentation officielle de filteringDeploymentDescriptors .