About jetty:run-exploded, the documentation says:
This goal is used to assemble your webapp into an exploded war and automatically deploy it to Jetty.
...
- Invokes the execution of the lifecycle phase
package
prior to executing itself.
So the behavior you are describing is the normal behavior and it makes sense as jetty can't expect to find something under target if it hasn't been built and as the package
phase could involve things like filtering (so filtering must occur).
That said, a few things might help (I'm not sure I understood clearly your goal so I'll mention several options). First option, you could use manual
reload instead of automatic
to avoid the automatic redeployment. About the manual
mode, the documentation writes:
"Manual Reloading" As of Jetty 6.2.0pre0 a new feature to control webapp redeployment will be available.
The configuration parameter is:
<reload>[manual|automatic]</reload>
When set to manual, no automatic
scanning and redeployment of the
webapp is done. Rather, the user can
control when the webapp is reloaded by
tapping the carriage return key. Set
to automatic the scanning and
automatic redeployment is performed at
intervals controlled by the
scanIntervalSeconds parameter. The choice of reloading paradigm can also
be configured on the command line by
use of the -Djetty.reload system
parameter. For example: "mvn
-Djetty.reload=manual jetty:run" would force manual reloading, regardless of
what is configured in the project pom.
Similarly: "mvn
-Djetty.reload=automatic -Djetty.scanIntervalSeconds=10 jetty:run" will force automatic
background reloading with a sweep
every 10 seconds, regardless of the
configuration in the project pom.
Another option would be to create another "empty" war modules (in the maven sense) to start jetty from and to use the jettyConfig optional parameter to set:
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 be deployed, or you have other jetty objects that cannot be configured from the plugin.
This way, you should be able to deploy the static content from the other webapp. I don't think that the additional content will be "watched" but you can always combine it with the manual mode if required. Never tested though.