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.
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.
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>
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:
jettyXml
parameter).
contextXml
parameter.webApp
element. TODO [http://wiki.eclipse.org/Jetty/Tutorial/RequestLo] on
configuring request logs.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.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:
/home/jesse/src/releases/jetty-documentation/target/checkout/src/main/webapp
/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>
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.
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.
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>
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.
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>
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>
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:
cntrl-c
in the terminal window to stop the plugin, which also stops the forked
JVM.mvn jetty:stop
to stop the forked JVM, which also stops the plugin.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.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.
The following sections provide information on additional configuration options.
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>
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.
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.
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.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).
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>
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>
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)
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>
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>
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>
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.
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.
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>
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>