[jetty-users] jetty-maven-plugin forked execution

[Jan Bartel <janb@xxxxxxxxxxx>]

https://jira.codehaus.org/browse/JETTY-991

I've been doing some work on the above issue in order to remove the
dependency on the jetty-runner jar
that was introduced recently to support a forked execution of the
jetty plugin. I've taken this opportunity
to revisit the code. The work is being done in the branch named
"forked-runner" on the codehaus git
repo if you're interested.

What I've implemented so far is the ability to fork off a new process
to run jetty on the *unassembled* webapp.
So, its now very similar to the jetty:run mojo, but just in a new jvm.

I'm posting this to the jetty lists to solicit some feedback to help
me complete the work. In particular,
I'd really appreciate some use-cases from people who have been asking
for forked executions - by that
I mean small example webapps with pom configuration for the style of
plugin execution that is wanted.

As background, here's some info on how the new "mvn jetty:run-forked"
mojo is configured:

<configure>
 <!-- where the unassembled web.xml is (optional: default value shown) -->
 <webXml>${basedir}/src/main/webapp/WEB-INF/web.xml</webXml>

 <!-- where the root of the unassembled webapp is (optional: default
value shown) -->
 <webAppSourceDirectory>${basedir}/src/main/webapp</webAppSourceDirectory>

 <!-- where the tmp directory for the webapp is (optional: default
value shown) -->
 <tmpDirectory>${project.build.directory}/tmp</tmpDirectory>

 <!-- where the classes for the webapp are (optional: default value shown) -->
 <classesDirectory>${project.build.outputDirectory}</classesDirectory>

 <!-- where the test classes for the webapp are (optional: default
value shown) -->
 <testClassesDirectory>${project.build.testOutputDirectory}</testClassesDirectory>

 <!-- whether or not to put the test classes on the webapp's
classpath (default shown) -->
 <useTestClasspath>false</useTestClasspath>

 <!-- context xml file to configure the WebAppContext (optional) -->
 <contextXml>src/main/config/context.xml</contextXml>

 <!-- the path for the deployed webapp (mandatory) -->
 <contextPath>/foo</contextPath>

 <!-- comma sep list of jetty xml files to configure the Server (optional) -->
 <jettyXml>src/main/config/jetty1.xml,src/main/config/jetty2.xml</jettyXml>

 <!-- stop port -->
 <stopPort></stopPort>

 <!-- stop key -->
 <stopKey></stopKey>

 <!-- skip the execution or not (default shown) -->
 <skip>false</skip>
</configure>

You'll notice the configuration is somewhat different to the "mvn
jetty:run" config. For example,
you cannot use the <webAppConfig> element to configure the
WebAppContext representing the
webapp, nor the <connectors>, <loginServices> and <requestLog> to
configure the jetty Server.
Instead, you use context xml and jetty xml files instead (actually,
I've been intending  for some time
to entirely remove the <connectors>, <loginServices> and <requestLog>
elements, as using jetty xml
files is a much better way to do it).

When run with "mvn jetty:run-forked" the above example would start up
a separate jvm, and start a
Server which is configured by the src/main/config/jetty1.xml and
src/main/config/jetty2.xml files, and
then create and deploy a WebAppContext to it representing the
unassembled webapp that is configured
by a combination of the src/main/config/context.xml file, the pom, and
generated by the plugin.

The forked vm will continue to execute until a "mvn jetty:stop" is
issued (in another terminal window).

What is not clear to me is what is the desired lifecycle relationship
between the plugin and the forked process:

 -should the plugin wait for the child process to finish?
 or
 -should the plugin finish immediately after forking?

 - if the plugin finishes immediately, how will we avoid orphan jetty
processes?

 -if the plugin waits for the child process to finish, does stopping
the plugin also stop the forked process?

If some of you could provide example webapps and poms of how you'd
like to run these forked executions
that I could test with, that would be very helpful.

thanks
Jan