Being able to run the jetty maven plugin on your webapp – but in a freshly forked jvm – is a feature that has been requested for a loooong time. With jetty-7.5.2 release, this feature has been implemented, and it even works on your unassembled webapp.
How to Run
That will kick off a Jetty instance in a brand new jvm and deploy your unassemabled webapp to it. The forked Jetty will keep on running until either:
- you execute a
mvn jetty:stop(in another terminal window)
- you <cntrl-c> the plugin
The plugin will keep on executing until either:
- you stop it with a <cntrl-c>
- the forked jvm terminates
NOTE: I’m interested in obtaining feedback about the lifecycles of the plugin and the forked Jetty. Is the lifecycle linkage that I’ve implemented the way you want to use it? Do you want the forked jvm to continue on, even if the plugin exits? Please post your input to the Jetty list at
How to Configure
You need a few different configuration parameters from the usual
jetty:run ones. Let’s look at an example:
You need to specify the
stopPort so that you can control the forked Jetty using the handy maven goal
You can use the
jettyXml parameter to specify a comma separated list of jetty xml configuration files that you can use to configure the container. There’s nothing special about these config files, they’re just normal jetty configuration files. You can also use this parameter with the
jetty:run goal too.
contextXml parameter specifies the location of a webapp context xml configuration file. Again, this is a normal jetty context xml configuration file. You can also use this with the
jetty:run goal too, either in conjunction with, or instead of, the <webAppConfig> parameter (which configures the webapp right there in the pom). As the
jetty:run-forked goal does NOT support the <webAppConfig> element, you MUST use
contextXml if you need to configure the webapp.
contextPath parameter specifies the context path at which to deploy the webapp. You can use this as a simple shortcut instead of the
contextXml parameter if you have no other configuration that you need to do for the webapp. Or, you can specify both this AND the
contextXml parameter, in which case the
contextPath takes precedence over the context path inside the context xml file.
tmpDirectory is the location of a temporary working directory for the webapp. You can configure it either here, or in a
contextXml file. If specified in both places, the
tmpDirectory takes precedence.
jvmArgs parameter, you can specify an arbitrary list of args that will be passed as-is to the newly forked jvm.
There’s also the same parameters as the
mvn jetty:run goal:
truethe execution of the plugin is skipped
true, jars of
<scope>test</scope>and the test classes are placed on the webapp’s classpath inside the forked jvm
true, jars of
<scope>provided</scope>are placed on the container’s classpath inside the forked jvm
classesDirectory– the location of the classes for the webapp
testClassesDirectory– the location of the test classes
webAppSourceDirectory– the location of the static resources for the webapp
Also, just like the
mvn jetty:run case, if you have dependencies that are
<type>war</type> , then their resources will be overlaid onto the webapp when it is deployed in the new jvm.