Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery

Configuring the Jetty Maven Plugin

Quick Start: Get Up and Running
Running and Deploying
Configuring the Jetty Container
Configuring Your WebApp
jetty:run-forked: Running an Unassembled Webapp in a Separate JVM
jetty:start: Starting Jetty without First Executing the Build Up to test-compile Phase
More Configuration Options

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.

Note

The information on this page refers to the Jetty Maven plugin, for versions Jetty 7 and later. If you're using the plugin with Jetty 6 (you should really upgrade), see the Maven Jetty Plugin guide at Codehaus.

Important

You need to use Maven 3 for jetty-7.5.3 and later releases.

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, 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:<var>goalname</var>

    

Configuring the Jetty Container

These configuration elements set up the Jetty environment in which your webapp executes. They are common to all goals.

  • connectors (Optional)–A list of org.eclipse.jetty.server.Connector objects, which are the port listeners for Jetty. If you don't specify any, Jetty configures an NIO org.eclipse.jetty.server.nio.SelectChannelConnector 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 instead configure the connectors in a standard //TO DO xref//[[http://wiki.eclipse.org/Jetty/Reference/jetty.xml jetty xml config]] file and put its location into the jettyXml parameter.
  • jettyXml (Optional)–The location of a jetty.xml file to apply 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 you cannot configure 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)–Allows you to configure System properties for the execution of the plugin. For more information, see TODO [[#Setting System Properties|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 for Jetty 6.1.15rc4 and later.
  • 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 (see Deploying Contexts), as specified in the contextXml parameter.
    • In the webApp element. TODO [http://wiki.eclipse.org/Jetty/Tutorial/RequestLo] on configuring request logs.

Configuring Your WebApp

These configuration parameters apply to your webapp. They are common to all goals.

  • webApp –Represents an extension to the class TODO org.eclipse.jetty.webapp.WebAppContext. You can use any of the setter methods on this object 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 /jetty-documentation 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 you don't supply one, Jetty uses a default file baked into the jetty-webapp.jar.
    • overrideDescriptor –The path to a web.xml file that Jetty applies after reading your web.xml. 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 /home/jesse/src/releases/jetty-documentation/target/checkout/target/classes/tmp.
    • baseResource –The path from which Jetty serves 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.
  • 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 /home/jesse/src/releases/jetty-documentation/target/checkout/src/main/webapp
  • classes in /home/jesse/src/releases/jetty-documentation/target/checkout/target/classes
  • web.xml in /home/jesse/src/releases/jetty-documentation/target/checkout/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.

You do not ned to assemble the webapp 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 that 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 /home/jesse/src/releases/jetty-documentation/target/checkout/target/test-classes.
  • 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. Be aware that this is 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 /home/jesse/src/releases/jetty-documentation/target/checkout/src/main/webapp. If your static sources are in a different location, set this parameter accordingly.
  • jettyEnvXml (Optional)–Location of a jetty-env.xml file, which allows you to make JNDI bindings that satisfy env-entry, resource-env-ref, and resource-ref linkages in the web.xml that are scoped only to the webapp and not shared with other webapps that you might be deploying at the same time (for example, by using a jettyConfig file).
  • scanTargets (Optional)–A list of files and directories to periodically scan in addition to those the plugin automatically scans.
  • 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 scanTargetsList of scanTargetPatterns, 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 exits. 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>/home/jesse/src/releases/jetty-documentation/target/checkout/src/staticfiles</webAppSourceDirectory>
          <webAppConfig>
            <contextPath>/</contextPath>
            <descriptor>/home/jesse/src/releases/jetty-documentation/target/checkout/src/over/here/web.xml</descriptor>
            <jettyEnvXml>/home/jesse/src/releases/jetty-documentation/target/checkout/src/over/here/jetty-env.xml</jettyEnvXml>
          </webAppConfig>
          <classesDirectory>/home/jesse/src/releases/jetty-documentation/target/checkout/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 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 is the location of the built WAR file. This defaults to /home/jesse/src/releases/jetty-documentation/target/checkout/target/jetty-documentation-9.0.0.M2.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>/home/jesse/src/releases/jetty-documentation/target/checkout/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 is the location of the exploded WAR. This defaults to /home/jesse/src/releases/jetty-documentation/target/checkout/target/jetty-documentation-9.0.0.M2, 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>/home/jesse/src/releases/jetty-documentation/target/checkout/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:


<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <war>/home/jesse/src/releases/jetty-documentation/target/checkout/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 was 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 /jetty-documentation. Overrides a setting inside a contextXml> file.
  • webAppSourceDirectory (Optional)–The location of the static resources for your webapp. Defaults to src/main/webapp. Overrides 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. Overrides a Set name="descriptor" inside a contextXml file.
  • tmpDirectory (Optional)–The location of the temporary work directory. Defaults to target/tmp. Overrides a Set name="tempDirectory"> inside a contextXml file.
  • classesDirectory (Optional)–The location of the compiled classes for the webapp. Defaults to /home/jesse/src/releases/jetty-documentation/target/checkout/target/classes.
  • testClassesDirectory (Optional)–The location of the compiled test classes for the webapp. Defaults to /home/jesse/src/releases/jetty-documentation/target/checkout/target/test-classes.
  • 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.

To deploy your unassembled web app to Jetty running in a new JVM:


    mvn jetty:run-forked

    

Jetty continues to execute until you either:

  • Press cntrl-c in the terminal window to stop the plugin, which also stops the forked JVM.
  • Use mvn jetty:stop to stop the forked JVM, which also stops the plugin.

Note

If you want to set a custom port, you need to specify it in a jetty.xml file rather than setting the <connector> <port></port> </connector>tags. You can specify the location of the jetty.xml using the jettyXml parameter.

jetty:start: Starting Jetty without First Executing the Build Up to test-compile Phase

This goal was new in jetty-7.6.0. We designed it to use with an execution binding in your pom.xml. It is similar to the jetty:run goal, however 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 Configuration Options

The following sections provide information on additional configuration options.

Excluded Goals

Your webapp might not 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, cause the plugin to print an informative message and exit immediately:


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

        

Manual Reload

You might not want Jetty to automatically reload and redeploy your webapp when something about it changes. For example, you might be doing a series of changes that you want to ignore until you're done. In that use, use the reload parameter:

reload (Optional)–Default value is automatic. If manual, a linefeed in the console can reload the context. If automatic, 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 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

For more help, use the mvn jetty:help command.

  • 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 properties you can set for that goal, in addition to its description.

Skipping Execution of Jetty

Similar 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 (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>/home/jesse/src/releases/jetty-documentation/target/checkout/src/etc/realm.properties</config>
      </loginService>
    </loginServices>
  </configuration>
</plugin>

        

Configuring Connectors for Jetty Maven Plugin

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 Overlaid 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 defined the same resource 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 the webapp has available these additional resources:


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

        

Using Multiple Webapp Root Directories

If you have external resources that you want to incorporate in the execution of a webapp, but which are not assembled into WARs, you can't use the overlaid WARs method described above, but you can tell Jetty the directories in which these external resources are located. At runtime, when Jetty receives a request for a resource, it searches all the locations to retrieve the resource. It's a lot like the overlaid WAR situation, but without the WAR. Here's a configuration example:


<configuration>
  <webApp>
    <contextPath>/jetty-documentation-9.0.0.M2</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 explicitly 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>
      
        

Note

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. To instruct Maven to look for the plugin in the groupId as defined, set a plugin group in a profile in settings.xml:

<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 want to deploy, or you can use the contextHandlers configuration element in the Jetty plugin configuration to do so. If you want to deploy webapp A, and 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>/home/jesse/src/releases/jetty-documentation/target/checkout../../B.war</war>
              <contextPath>/B</contextPath>
            </contextHandler>
            <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
              <war>/home/jesse/src/releases/jetty-documentation/target/checkout../../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

You can specify property name/value pairs that Jetty sets as System properties for the execution of the plugin. Note that if a System property 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.

Specifying System Properties in the POM

Here's an example of how to specify System properties in the POM:


<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>

          
Specifying System Properties in a File

You can also specify your System properties in a file. System properties you specify in this way DO NOT override System properties that 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>/home/jesse/src/releases/jetty-documentation/target/checkout/mysys.props</systemPropertiesFile>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
   </configuration>
</plugin>

          
See an error or something missing?
Contribute to this documentation at Github!