How to specify jetty-env.xml file for Maven Cargo plugin for Jetty?

Question

I am switching from the Maven plug-in to the Cargo plug-in (load-maven2-plugin), because Cargo will successfully run the WAR from Maven dependent modules. As part of the web application, we are working hard to externalize the entire configuration through JNDI. These JNDI definitions are web-specific and are therefore located in the jetty-env.xml file, which 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 to do this to indicate this in the Cargo plugin? Here I still have the configuration. This, of course, fails due to a missing 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> 

Answer 1

Mond's answer provoked the idea that perhaps I could use the Cargo configuration to include my (renamed and slightly modified) jetty-env.xml in the "contexts" directory. To my surprise, it just worked. Here is what I did:

In the configuration of my cargo, 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 upload its own context file AFTER it had copied mine, but it was smart enough to copy my last.

Answer 2

In accordance with CARGO-804 , the Cargo Jetty deployer now supports embedding jetty-env.xml in your war (starting with version 1.0.3).

And to save jetty-env.xml outside of your “real” war, my suggestion would be to create an additional military module to accommodate the jetty-env.xml and set Cargo to combine WAR files (pay special attention to the <extensions>true</extensions> , which is important as indicated in CARGO-524 ).

Answer 3

I have the same problem and desire to have a clean install. I was not attracted to the merging of WAR files. Instead, I use assembly to support a ZIP file of all external properties. As a separate module, I can deploy the contents of a ZIP file to a JETTY environment. In turn, I use the way Jetty uses the name of a web application to download a free environment file (for webapps / foo.war Jetty uses contexts /foo.xml for configuration). Thus, although it is not as compact as a pure Cargo solution, I prefer it, since the WAR file is unrivaled in its development throughout the entire process of promotion. The solution is also a general mechanism for managing all configuration activities. I can point out more details if anyone is interested.

Answer 4

Something else I want to do is 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> 

This is a bit more complicated than I like, but allows you to filter properties by adding them to Jetty. This allows you to redefine passwords and other sensitive data using system properties. We use Bamboo (I think Hudson is similar), and you can set up plans for the environment. Plans may be subject to access control. This allows us to have one place to set all the deployment properties, so there will be no more admins cracking Unix blocks.