Jetty/Feature/Jetty Maven Plugin

This documentation ONLY refers to using the jetty-maven-plugin with Jetty 7.x or Jetty 8.x which are both EOL. All development and stable releases are being performed with Jetty 9, 10 and 11. Direct links to documentation:

Jetty 9.x: https://www.eclipse.org/jetty/documentation/jetty-9/index.html#jetty-maven-plugin

Jetty 10.x: https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#jetty-maven-plugin

Jetty 11.x: https://www.eclipse.org/jetty/documentation/jetty-11/programming-guide/index.html#jetty-maven-plugin

Jetty documentation hub: http://www.eclipse.org/jetty/documentation

If you're using the plugin with the EOL Jetty 6, see the Jetty 6 Maven Plugin guide at codehaus. It is called the jetty-maven-plugin. In previous versions it was the maven-jetty-plugin.

Introduction

The Jetty Maven plugin is useful for rapid development and testing. You can add it to any webapp project that is structured according to the usual Maven defaults. The plugin can then periodically scan your project for changes and automatically redeploy the webapp if any are found. This makes the development cycle more productive by eliminating the build and deploy steps: you use your IDE to make changes to the project, and the running web container automatically picks them up, allowing you to test them straight away.

You will need to use maven 3 from jetty-7.5.3 release going forwards.

Feature

Quick Start: Get Up and Running

First, add jetty-maven-plugin to your pom.xml definition:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
</plugin>

Then, from the same directory as your root pom.xml, simply type:

 mvn jetty:run

This starts Jetty and serves up your project on http://localhost:8080/.

Jetty continues to run until you stop it. While it runs, it periodically scans for changes to your project files, so if you save changes and recompile your class files, Jetty redeploys your webapp, and you can instantly test the changes you just made.

Stopping the Plugin

You can terminate the plugin with a <ctrl-c> in the terminal window where it is running.

Running and Deploying

The jetty-maven-plugin has a number of distinct Maven goals. Each goal is an action you can run to accomplish a specific task, or to work with a particular web application setup. You might need to insert goal-specific configuration to run it properly.

To run the jetty-maven-plugin with a particular goal, use this command:

 mvn jetty:goalname

Here are the configuration elements that are common to all goals:

Configuring the Jetty Container

These configuration elements set up the Jetty environment in which your webapp executes.

• <connectors> Optional A list of org.eclipse.jetty.server.Connector objects, which are the port listeners for Jetty. If you don't specify any, an NIO org.eclipse.jetty.server.nio.SelectChannelConnector will be configured on port 8080. You can change this default port number by using the system property jetty.port on the command line, for example, "mvn -Djetty.port=9999 jetty:run". Alternatively, you can specify as many connectors as you like. You could also instead configure the connectors in a standard [jetty xml config] file and put its location into the <jettyXml> parameter.

• <jettyXml> Optional The location of a jetty.xml file that will be applied in addition to any plugin configuration parameters. You might use it if you have other webapps, handlers, etc. to deploy, or if you have other Jetty objects that cannot be configured from the plugin.

• <scanIntervalSeconds> Optional The pause in seconds between sweeps of the webapp to check for changes and automatically hot redeploy if any are detected. By default this is 0, which disables hot deployment scanning. A number greater than 0 enables it.

• <systemProperties> Optional Allow you to configure System properties for the execution of the plugin. For more information, see Setting System Properties.

• <systemPropertiesFile> Optional A file containing System properties to set for the execution of the plugin. Settings that you make here do not override any system properties already set on the command line, by the JVM, or in the POM via systemProperties. Available from Jetty 6.1.15rc4.

• <loginServices> Optional A list of org.eclipse.jetty.security.LoginService implementations. Note that there is no default realm. If you use a realm in your web.xml you can specify a corresponding realm here. You could instead configure the login services in a jetty xml file and add its location to the <jettyXml> parameter.

• <requestLog> Optional An implementation of the org.eclipse.jetty.server.RequestLog request log interface. An implementation that respects the NCSA format is available as org.eclipse.jetty.server.NCSARequestLog. There are three other ways to configure the RequestLog:
  • In a jetty xml config file (specified in the <jettyXml> parameter).
  • In a context xml config file (specified in the <contextXml> parameter).
  • In the <webApp> element. Configuring Request Logs tutorial.

Configuring Your WebApp

These configuration parameters apply to your webapp. They should apply to all goals, except for run-forked and stop:

• <webApp> Represents an extension to the class org.eclipse.jetty.webapp.WebAppContext. Any of the setter methods on this object can be used to configure your webapp. Here are a few of the most useful ones:
  • <contextPath> The context path for your webapp. By default, this is set to the /${project.artifactId} from the project's pom.xml.
  • <descriptor> The path to the web.xml file for your webapp.
  • <defaultsDescriptor> The path to a webdefault.xml file that will be applied to your webapp before the web.xml. If none is supplied, Jetty uses a default one baked into the jetty-webapp.jar.
  • <overrideDescriptor> The path to a web.xml file that will be applied after your web.xml is read. You can use this to replace or add configuration.
  • <tempDirectory> The path to a dir that Jetty can use to expand or copy jars and jsp compiles when your webapp is running. The default is ${project.build.outputDirectory}/tmp
  • <baseResource> the path from which Jetty will serve static resources. Defaults to src/main/webapp.
  • <resourceBases> use instead of <baseResource> if you have multiple dirs from which you want to serve static content. This is an array of dir names.
  • <baseAppFirst> Optional. Defaults to "true". Controls whether any overlayed wars are added before or after the original base resource(s) of the webapp.
  • <jettyEnvXml> Optional. Location of a jetty-env.xml file, which allows you to make JNDI bindings that satisfies <env-entry>, <resource-env-ref> and <resource-ref> linkages in the web.xml. Note that these can also be made in a <jettyXml> file if you want them to apply to more than one webapp.
  • <containerIncludeJarPattern>. Since jetty-8.1.x. Optional. A pattern to match against the urls of the jars on the container path to select those that should be examined for things like META-INF fragments, resources, tlds and class inheritance hierarchy (used with servlet container initializers).
  • <webInfIncludeJarPattern>. Since jetty-8.1.6. Optional. A pattern to match against the urls of the jars considered to be on the webapp's WEB-INF classpath to select those that should be examined for META-INF fragments, resources, tlds, and class inheritance hierarchy (used with servlet container initializers). The default is to potentially examine them all, subject to any ordering exclusions configured in web.xml.
• <contextXml> Optional The path to a context xml file that is applied to your webapp AFTER the <webApp> element.

jetty:run : Running an unassembled webapp

The run goal runs on a webapp that does not have to be built into a WAR. Instead, Jetty deploys the webapp from its constituent sources. It looks for the constituent parts of a webapp in the maven default project locations, although you can override these in the plugin configuration. For example, by default it looks for:

• resources in ${basedir}/src/main/webapp
• classes in ${project.build.outputDirectory}
• web.xml in ${basedir}/src/main/webapp/WEB-INF/

The plugin automatically ensures the classes are rebuilt and up-to-date before deployment. If you change the source of a class and your IDE automatically compiles it in the background, the plugin picks up the changed class.

The webapp does not need to be assembled into a WAR, saving time during the development cycle. Once invoked, you can configure the plugin to run continuously, scanning for changes in the project and automatically performing a hot redeploy when necessary. Any changes you make are immediately reflected in the running instance of Jetty, letting you quickly jump from coding to testing, rather than going through the cycle of: code, compile, reassemble, redeploy, test.

Here is a small example, which turns on scanning for changes every ten seconds, and sets the webapp context path to "/test":

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
  </configuration>
</plugin>

Configuring additional parameters

In addition to the <webApp> element which is common to most goals, the jetty:run goal supports:

• <classesDirectory> – Location of your compiled classes for the webapp. You should rarely need to set this parameter. Instead, you should set <build><outputDirectory> in your pom.xml.
• <testClassesDirectory> – Location of the compiled test classes for your webapp. By default this is ${project.build.testOutputDirectory}.
• <useTestScope> – If true, the classes from <testClassesDirectory> and dependencies of scope "test" are placed first on the classpath. By default this is false.
• <useProvidedScope> - If true, the dependencies with scope "provided" are placed onto the container classpath. Note: NOT the webapp classpath, as "provided" indicates that these dependencies would normally be expected to be provided by the container. You should very rarely ever need to use this. Instead, you should copy the provided dependencies as explicit dependencies of the <plugin> instead.
• <webAppSourceDirectory> – By default, this is set to ${basedir}/src/main/webapp. If your static sources are in a different location, set this parameter accordingly.
• <scanTargets> –Optional A list of files and directories to periodically scan in addition to those automatically scanned by the plugin.
• <scanTargetPatterns> –Optional If you have a long list of extra files you want scanned, it is more convenient to use pattern matching expressions to specify them instead of enumerating them with the <scanTargets>–List of <scanTargetPattern>s, each consisting of a <directory,> and <including> and/or <excluding> parameters to specify the file matching patterns.
• <skip> - Optional Default is false. If true, the execution of the plugin will exit. Same as setting the SystemProperty -Djetty.skip on the command line.

Here's an example:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <webAppSourceDirectory>${basedir}/src/staticfiles</webAppSourceDirectory>
          <webAppConfig>
            <contextPath>/</contextPath>
            <descriptor>${basedir}/src/over/here/web.xml</descriptor>
            <jettyEnvXml>${basedir}/src/over/here/jetty-env.xml</jettyEnvXml>
          </webAppConfig>
          <classesDirectory>${basedir}/somewhere/else</classesDirectory>
          <scanTargets>
            <scanTarget>src/mydir</scanTarget>
            <scanTarget>src/myfile.txt</scanTarget>
          </scanTargets>
          <scanTargetPatterns>
            <scanTargetPattern>
              <directory>src/other-resources</directory>
              <includes>
                <include>**/*.xml</include>
                <include>**/*.properties</include>
              </includes>
              <excludes>
                <exclude>**/myspecial.xml</exclude>
                <exclude>**/myspecial.properties</exclude>
              </excludes>
            </scanTargetPattern>
          </scanTargetPatterns>
        </configuration>
      </plugin>
  </plugins>
</project>

If, for whatever reason, you cannot run on an unassembled webapp, the goals run-war and run-exploded will work on unassembled webapps.

jetty:run-war : Running an assembled webapp as a war

This goal first packages your webapp as a WAR file and then deploys it to Jetty. If you set a non-zero scanInterval Jetty watches your pom.xml and the WAR file; if either changes, it redeploys the war.

Configuring the war

• <war> The location of the built WAR file. This defaults to ${project.build.directory}/${project.build.finalName}.war. If this is not sufficient, set it to your custom location.

Here's how to set it:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <war>${basedir}/target/mycustom.war</war>
        </configuration>
      </plugin>
  </plugins>
</project>

jetty:run-exploded  : Running an assembled webapp as an expanded WAR

The run-exploded goal first assembles your webapp into an exploded WAR file and then deploys it to Jetty. If you set a non-zero scanInterval, Jetty watches your pom.xml, WEB-INF/lib, WEB-INF/classes and WEB-INF/web.xml for changes and redeploys when necessary.

Configuring the exploded war

• <war> The location of the exploded WAR. This defaults to ${project.build.directory}/${project.build.finalName}, but you can override the default by setting this parameter.

Here's how to set it:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <configuration>
          <war>${basedir}/target/myfunkywebapp</war>
        </configuration>
      </plugin>
  </plugins>
</project>

jetty:deploy-war  : Running a pre-assembled war

This is basically the same as jetty:run-war, but without assembling the war of the current module. Unlike run-war, the phase in which this plugin executes is not bound to the "package" phase.

For example, you might want to start Jetty on the test-compile phase and stop Jetty on the test-phase. Here's the configuration for that:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <war>${basedir}/target/mycustom.war</war>
        </configuration>
        <executions>
          <execution>
            <id>start-jetty</id>
            <phase>test-compile</phase>
            <goals>
              <goal>deploy-war</goal>
            </goals>
            <configuration>
              <daemon>true</daemon>
              <reload>manual</reload>
            </configuration>
          </execution>
          <execution>
            <id>stop-jetty</id>
            <phase>test</phase>
            <goals>
              <goal>stop</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
  </plugins>
</project>

jetty:run-forked  : Running an unassembled webapp in a separate jvm

This goal is new in jetty-7.5.2. You can force jetty to start the webapp in a new jvm, optionally passing arguments to the jvm. Unlike the other goals, this one does not share all the same configuration parameters (although a lot of them are the same, so that you can use many of the goals with the same configuration). The configuration options are:

• <jettyXml> The locations of jetty xml configuration files used to configure the container in the new jvm.

• <contextXml> Optional. The location of a context xml file to configure the webapp in the new jvm.

• <contextPath> Optional. The context path for the webapp in the new jvm. Defaults to "/${project.artifactId}". This will override a setting inside a <contextXml> file.

• <webAppSourceDirectory> Optional. The location of the static resources for your webapp. Defaults to "src/main/webapp". This will override a <Set name="baseResource"> setting inside a <contextXml> file.

• <resourceDirs> Optional. New in jetty-7.6.5. An array of directories containing static content that form the resource base for your webapp, in conjuction with the <webAppSourceDirectory>. See also <baseAppFirst>.

• <baseAppFirst> Optional. New in jetty-7.6.5. Defaults to "true". Controls whether the <webAppSourceDirectory> or <resourceDirs> are first on the list of resources that form the base resource for the webapp.

• <webXml> Optional. The location of the web.xml file. Defaults to "src/main/webapp/WEB-INF/web.xml". This will override a <Set name="descriptor"> inside a <contextXml> file.

• <tmpDirectory> Optional. The location of the temporary work directory. Defaults to "target/tmp". This will override a <Set name="tempDirectory"> inside a <contextXml> file.

• <classesDirectory> Optional. The location of the compiled classes for the webapp. Defaults to "${project.build.outputDirectory}"

• <testClassesDirectory> Optional. The location of the compiled test classes for the webapp. Defaults to "${project.build.testOutputDirectory}"

• <useTestScope> Optional. Defaults to "false". If true, the test classes and dependencies of scope "test" are placed on the webapp's classpath.

• <useProvidedScope> Optional. Defaults to "false". If true, the dependencies of scope "provided" are placed on the jetty container's classpath.

• <stopPort> Mandatory. A port number for jetty to listen on to receive a stop command to cause it to shutdown. If configured, the stopKey is used to authenticate an incoming stop command.

• <stopKey> Mandatory. A string value that has to be sent to the stopPort to authenticate the stop command.

• <skip> Optional. Defaults to "false". If true, the execution of this plugin is skipped.

• <jvmArgs> Optional. A String representing arbitrary arguments to pass to the forked jvm.

• <waitForChild> New in jetty-7.6.5. Optional. Defaults to "true". If true, the parent waits for the exec'ed jetty to complete. If false, the parent completes, leaving the exec'ed jetty process running, in which case you need to use mvn jetty:stop to kill it.

To deploy your unassembled web app to jetty running in a new jvm:

   mvn jetty:run-forked

With <waitForChild>true</waitForChild>:

The jetty plugin will continue to execute until either -

• you hit <cntrl-c> in the terminal window to stop the plugin, which will also stop the forked jvm

or

• you use "mvn jetty:stop" to stop the forked jvm, which will also stop the plugin

With <waitForChild>false</waitForChild>:

The jetty plugin will fork the child process and then exit.

NOTE: if you would like to set a custom port, you will need to specify it in a jetty.xml file rather than setting the <connector><port></port></connector> tags. The location of the jetty.xml can be specified using the jettyXml parameter.

jetty:start  : Starting jetty without first executing the build up to "test-compile" phase

This goal is new in jetty-7.6.0. This goal is designed to be used with an execution binding in your pom.xml. It is just like the jetty:run goal, however the difference is that it does NOT first execute the build up until the "test-compile" phase to ensure that all necessary classes and files of the webapp have been generated. This is most useful when you want to control the start and stop of jetty via execution bindings in your pom.xml.

For example, you can configure the plugin to start your webapp at the beginning of your unit tests and stop at the end. To do this, you need to set up a couple of <execution> scenarios for the Jetty plugin and use the <daemon>true</daemon> configuration option to force Jetty to execute only while Maven is running, instead of running indefinitely. You use the pre-integration-test and post-integration-test Maven build phases to trigger the execution and termination of Jetty:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <stopKey>foo</stopKey>
    <stopPort>9999</stopPort>
  </configuration>
  <executions>
    <execution>
      <id>start-jetty</id>
      <phase>pre-integration-test</phase>
      <goals>
        <goal>start</goal>
      </goals>
      <configuration>
       <scanIntervalSeconds>0</scanIntervalSeconds>
       <daemon>true</daemon>
      </configuration>
    </execution>
    <execution>
      <id>stop-jetty</id>
      <phase>post-integration-test</phase>
      <goals>
        <goal>stop</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Of course, you can use this goal from the command line (mvn jetty:start), however, you need to be sure that all generated classes and files for your webapp are already present first.

More

Excluded Goals

Sometimes, your webapp might simply not be able to work with one of the goals, for example "jetty:run". In this case, use the <excludedGoals> parameter:

• <excludedGoals> Optional Set to a comma separated list of jetty goal names which, if executed, will cause the plugin to print an informative message and exit immediately:

<configuration>
   <excludedGoals>run,run-exploded</excludedGoals>
</configuration>

Manual Reload

Sometimes you may not want jetty to automatically reload and redeploy your webapp when something about it has changed. For example, you may be doing a series of changes and you want to ignore them all until you're done. In that use, use the <reload> parameter:

• <reload> Optional Default value is automatic. If 'manual' then the context can be reloaded by a linefeed in the console. If 'automatic' then traditional reloading on changed files is enabled.

Stopping the plugin from Another Terminal Window

If you want to use mvn jetty:stop, you need to configure the plugin with a special port number and key that you also supply by executing the stop goal:

• <stopPort> A port number for jetty to listen on to receive a stop command to cause it to shutdown.
• <stopKey> A string value that has to be sent to the stopPort to validate the stop command.

Here's a configuration example:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <stopPort>9966</stopPort>
    <stopKey>foo</stopKey>
  </configuration>
</plugin>

Then, while Jetty is running, type:

   mvn jetty:stop

The <stopPort> must be free on the machine you are running on. If this is not the case, you get an "Address already in use" error message after the "Started SelectedChannelConnector ..." message.

Using mvn jetty:help for More Help

mvn jetty:help prints the list of goals for the jetty-maven-plugin, with a description of each goal.

mvn jetty:help -Ddetail=true -Dgoal=<goal-name> prints a list of the settable properties for that goal, in addition to its description.

Skipping execution of jetty

Similarly to the well known system property "mvn.test.skip", you can define the system property "jetty.skip" to prevent jetty running. This is most useful when configuring jetty for execution during integration testing and you want to skip the tests:

   mvn -Djetty.skip=true

You can also use the <skip> configuration parameter to skip jetty during certain executions (see above).

Configuring Security Settings

You can configure LoginServices (this was known as UserRealms in Jetty 6) in the plugin. Here's an example of setting up the HashLoginService for a webapp:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webAppConfig>
      <contextPath>/test</contextPath>
    </webAppConfig>
    <loginServices>
      <loginService implementation="org.eclipse.jetty.security.HashLoginService">
        <name>Test Realm</name>
        <config>${basedir}/src/etc/realm.properties</config>
      </loginService>
    </loginServices>
  </configuration>
</plugin>

Configuring Connectors

You can configure a list of org.eclipse.jetty.server.Connector objects for the plugin. If you don't specify any, an NIO org.eclipse.jetty.server.nio.SelectChannelConnector is configured on port 8080. You can change this default port number by using the system property jetty.port on the command line, for example "mvn -Djetty.port=9999 jetty:run". Alternatively, you can specify as many connectors as you like. Here's an example of configuring a connector on a different port number:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
    <connectors>
       <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
          <port>9090</port>
          <maxIdleTime>60000</maxIdleTime>
       </connector>
     </connectors>
  </configuration>
</plugin>

Using Overlayed WARs

If your webapp depends on other WAR files, the Jetty Maven plugin is able to merge resources from all of them. The merging is fairly simple and does not support exclusions. The ordering of dependencies is important if you have the same resource defined in multiple files. There is no special configuration for this beyond simply declaring the dependencies.

For example, suppose our webapp depends on these two WARs:

<dependency>
      <groupId>com.acme</groupId>
      <artifactId>X</artifactId>
      <type>war</type>
</dependency>
<dependency>
      <groupId>com.acme</groupId>
      <artifactId>Y</artifactId>
      <type>war</type>
</dependency>

Suppose the webapps contain:

WebAppX:
 
/foo.jsp
/bar.jsp
/WEB-INF/web.xml
 
 
 
WebAppY:
 
/bar.jsp
/baz.jsp
/WEB-INF/web.xml
/WEB-INF/special.xml

Then our webapp will have available these additional resources:

/foo.jsp (X)
/bar.jsp (X)
/baz.jsp (Y)
/WEB-INF/web.xml (X)
/WEB-INF/sitemesh.xml (Y)

Multiple webapp root directories

If you have external resources that you want to incorporate in the execution of your webapp - but they're not assembled into wars so you can't use the Overlaid Wars method described above - then you can simply tell jetty the directories in which these external resources are located. At runtime, when jetty receives a request for a resource, it will look along all the locations to retrieve the resource. It's a lot like the overlaid war situation, without the war. Here's a configuration example:

<configuration>
  <webApp>
    <contextPath>/${build.finalName}</contextPath>
    <baseResource implementation="org.eclipse.jetty.util.resource.ResourceCollection">
      <resourcesAsCSV>src/main/webapp,/home/johndoe/path/to/my/other/source,/yet/another/folder</resourcesAsCSV>
    </baseResource>
  </webApp>
</configuration>

Using GZip Compression and Other Jetty Extensions

You must be explicit enable GZip compression and other Jetty extensions by adding a dependency on jetty-servlets:

      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>7.0.1.v20091125</version>
        <configuration>
          [...]
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-servlets</artifactId>
            <version>7.0.1.v20091125</version>
          </dependency>
        </dependencies>
      </plugin>

Setting the groupId
Maven by default looks for plugins with a groupId of org.apache.maven.plugins, even if the groupId is declared differently as above. In order to instruct Maven to look for the plugin in the groupId as defined, set a plugin group in a profile in settings.xml like so:

<profile>
  ...
  <pluginGroups>
    <pluginGroup>org.mortbay.jetty</pluginGroup>
  </pluginGroups>
</profile>

Running more than one webapp

You can use either a jetty.xml file to configure extra (pre-compiled) webapps that you wish to deploy, or you can use the contextHandlers configuration element in the jetty plugin configuration to do so. Say you have a webapp A, and you'd also like to deploy webapps B and C in the same jetty instance.

Putting the configuration in webapp A's pom.xml:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
      <contextHandlers>           
            <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
              <war>${basedir}../../B.war</war>
              <contextPath>/B</contextPath>
            </contextHandler>
            <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
              <war>${basedir}../../C.war</war>
              <contextPath>/B</contextPath>
            </contextHandler>
          </contextHandlers> 
  </configuration>
</plugin>

Alternatively, add a jetty.xml file to webapp A. Copy the jetty.xml file from the jetty distribution, and then add WebAppContexts for the other 2 webapps:

   <Ref id="Contexts">
       <Call name="addHandler">
         <Arg>
           <New class="org.eclipse.jetty.webapp.WebAppContext">
             <Set name="contextPath">/B</Set>
             <Set name="war">../../B.war</Set>
           </New>
         </Arg>
       </Call>
       <Call>
         <Arg>
           <New class="org.eclipse.jetty.webapp.WebAppContext">
             <Set name="contextPath">/C</Set>
             <Set name="war">../../C.war</Set>
          </New>
         </Arg>
       </Call>
   </Ref>

Then configure the location of this jetty.xml file into webapp A's jetty plugin:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
     <jettyXml>src/main/etc/jetty.xml</jettyXml>
   </configuration>
</plugin>

For either of these solutions, the other webapps must already have been built, and they are not automatically monitored for changes. You can refer either to the packed war file of the pre-built webapps or to their expanded equivalents.

Setting System Properties

As a convenience, you can specify property name/value pairs that Jetty sets as System properties for the execution of the plugin. NOTE however that some system properties MUST be set on the command line to take effect, as by the time maven runs their values have already been established.

NOTE also that configuring logging using this method of setting system properties may not work as the logging system may initialize BEFORE the jetty plugin can set the system properties.

You may find it useful instead to use the properties maven plugin directly in your pom to set system properties which must be evaluated before any jetty code executes. Eg:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-maven-plugin</artifactId>
  <version>1.0-alpha-2</version>
  <executions>
    <execution>
      <goals>
        <goal>set-system-properties</goal>
      </goals>
      <configuration>
        <properties>
          <property>
            <name>logback.configurationFile</name>
            <value>${project.baseUri}/resources/logback.xml</value>
          </property>
        </properties>
      </configuration>
    </execution>
  </executions>
</plugin>

In the Pom

Note that if a System property is found that is already set (for example, from the command line or by the JVM itself), then these configured properties DO NOT override them. This feature is useful to tidy up the command line and save a lot of typing. Here's an example:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <systemProperties>
      <systemProperty>
         <name>fooprop</name>
         <value>222</value>
       </systemProperty>
    </systemProperties>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
   </configuration>
</plugin>

As of jetty-7.6.5, you CAN cause the system properties defined in the pom to override those on the command line, by using the <force> parameter:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <systemProperties>
      <force>true</force>
      <systemProperty>
         <name>fooprop</name>
         <value>222</value>
       </systemProperty>
    </systemProperties>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
   </configuration>
</plugin>

In a File

You can also specify your System properties in a file. System properties specified in this way do NOT override System properties that have been set on the command line, by the JVM, or directly in the POM via systemProperties.

Here's an example of the file:

fooprop=222

Here's an example of configuring the file for the plugin, although you can instead specify the file by setting the System property (!) jetty.systemPropertiesFile on the command line:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <systemPropertiesFile>${basedir}/mysys.props</systemPropertiesFile>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
   </configuration>
</plugin>