问题
I am migrating from Maven's jetty plugin to the Cargo plugin (cargo-maven2-plugin) because Cargo will happily run WARs from dependent Maven modules. Within out web-app we have taken great pains to externalize all configuration through JNDI. These JNDI definitions are web-app specific and therefore are placed in a jetty-env.xml file that is outside the WAR. Using the Jetty plugin, we specified this file as follows:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<jettyEnvXml>${basedir}/target/config/jetty-env.xml</jettyEnvXml>
</configuration>
</plugin>
How does one go about specifying this within the Cargo Plugin? Here's the configuration I have so far. It is, of course, failing because of the absent JNDI configuration:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
<configuration>
<deployables>
<deployable>
<groupId>com.mycompany</groupId>
<artifactId>my-war-module</artifactId>
<type>war</type>
<properties>
<context>/</context>
</properties>
</deployable>
</deployables>
</configuration>
<wait>false</wait>
</configuration>
<executions>
......
</executions>
</plugin>
回答1:
According to CARGO-804, Cargo's Jetty deployer now supports embedding a jetty-env.xml inside your war (as of version 1.0.3).
And in order to keep the jetty-env.xml outside your "real" war, my suggestion would be to create an additional war module to host the jetty-env.xml file and configure Cargo to merge WAR files (pay a special attention to the <extensions>true</extensions> element which is important, as mentioned in CARGO-524).
回答2:
I share the same problem and desire to have a clean install. I was not attracted by the merging of WAR files. Instead I use an assembly to maintain a ZIP file of all external properties. As a separate module I can then deploy the contents of the ZIP file to the JETTY environment. In turn, I leverage how Jetty uses the name of the web app to load a complimentary environment file (for webapps/foo.war Jetty uses contexts/foo.xml for configuration). So, whilst it's not as compact as a pure Cargo solution I prefer it since the WAR file is unadulterated in its progress throughout the promotion process. The solution is also a general mechanism to manage all configuration activities. I can point to more details if anyone is interested.
回答3:
Mond's answer sparked an idea that perhaps I could use the configuration of Cargo to deposit my (renamed and slightly modified) jetty-env.xml into the "contexts" directory. To my amazement it Just Worked. Here what I did:
To my cargo configuration I added the following:
<configfiles>
<configfile>
<file>${basedir}/../config/jetty-env.xml</file>
<todir>contexts</todir>
<tofile>${jetty6.context}.xml</tofile>
</configfile>
</configfiles>
But in order to turn my jetty-env.xml into a real context.xml I added the following:
<!-- Activates the Jetty-Plus feature so we can create/share JNDI resources -->
<Array id="plusConfig" type="java.lang.String">
<Item>org.mortbay.jetty.webapp.WebInfConfiguration</Item>
<Item>org.mortbay.jetty.plus.webapp.EnvConfiguration</Item>
<Item>org.mortbay.jetty.plus.webapp.Configuration</Item>
<Item>org.mortbay.jetty.webapp.JettyWebXmlConfiguration</Item>
<Item>org.mortbay.jetty.webapp.TagLibConfiguration</Item>
</Array>
<!-- Miscellaneous properties that were take from the CARGO version of this file that is created automatically
(and then replaced by this file). If you ever upgrade Cargo you may need to change these. -->
<Set name="contextPath">/${jetty6.context}</Set>
<Set name="war">
<SystemProperty name="config.home" default="."/>/webapps/${jetty6.context}.war</Set>
<Set name="extractWAR">true</Set>
<Set name="defaultsDescriptor">
<SystemProperty name="config.home" default="."/>/etc/webdefault.xml</Set>
<Set name="ConfigurationClasses">
<Ref id="plusConfig" />
</Set>
I was worried that CARGO would dump its own context file AFTER it copied mine there, but it was smart enough to copy mine last.
回答4:
Something else I want to do is to filter properties. So far I have this:
<profile>
<id>deploy-properties</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<deployable.classifier>properties</deployable.classifier>
<deployable.type>zip</deployable.type>
<ys.imq.user>UserFromDeploymentPom</ys.imq.user>
<ys.imq.password>PasswordFromDeploymentPom</ys.imq.password>
</properties>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${deployable.artifactId}</artifactId>
<classifier>${deployable.classifier}</classifier>
<type>${deployable.type}</type>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
</execution>
</executions>
<configuration>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${deployable.artifactId}</artifactId>
<classifier>${deployable.classifier}</classifier>
<version>${project.version}</version>
<type>${deployable.type}</type>
<overWrite>true</overWrite>
<outputDirectory>/tmp/${deployable.artifactId}</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${deploy.jettyHome}</outputDirectory>
<overwrite>true</overwrite>
<resources>
<resource>
<directory>/tmp/${deployable.artifactId}</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Its a bit more complicated than I like but allows me to filter properties whilst adding them to Jetty. This enables passwords and other confidential data to be overriden using system properties. We are using Bamboo (I guess Hudson is similar) and one can adjust plans per environment. Plans can be subject to access control. This allows us to have one place to set all deployment properties, so no more admins hacking on the Unix boxes.
来源：https://stackoverflow.com/questions/4039655/how-to-specify-jetty-env-xml-file-for-maven-cargo-plugin-for-jetty