Jetty mavn plugin run-forked doesn't respect configuration set using file from contextXml option

Similar issue - the webapp being created by the maven plugin is NOT the webapp being configured by the forked process.

Stepan,

The values that are set via the configuration parameters such as contextPath, webXml, tmpDirectory etc must override those that are set inside the context.xml file, as that behaviour is standard throught the jetty maven plugin.

It is true that they will always be set to some value, as default values are provided for them via the maven parameter declaration annotations. However, if you don't like the default values, then you should be able to specify the values you want.

It seems that you want to be able to specify multiple locations for the base resource of the webapp. If I change the plugin so that you can specify multiple directories as comma separated list, will that meet your requirements?

Jan

Jan,

I think if user doesn't specify configuration parameters (such as contextPath or web resources) in the plugin configuration the default values (from the annotations) should not override the settings from context.xml file.

For instance if I specify in my context.xml file the 'context path' value and 'multiple base resources' they are not overridden by the default values from the maven plugin in case I execute the 'run' goal. And therefore the behavior should be the same for the 'run-forked' goal. (ie. for both goals I specified only the 'contextXml' option)

Yes, You're right I want to specify multiple locations for the base resources of the webapp and If you implement the comma separated solution it would help. Although I think it still leaves the bug unsolved.

Best regards,
Stepan

Stepan,

I've added a new parameter to allow you to specify multiple resource bases for a webapp. You use it like this:

<resourceDirs>
<resourceDir>$

/foo2</resourceDir>
</resourceDirs>

I'm still considering whether to change the behaviour of the context.xml file - currently it does NOT override as you noted. The jetty:run mojo DOES allow it to override, but that is accidental rather than desirable - as the <webApp> that is being configured in that case is the WebAppContext itself and constructed by maven, it is not possible to apply the context xml file before the instance is created.

Jan

Jan,
thanks for the work you've done!

I was thinking about the implementation and the different behavior for those two goals. What do you think about leaving the fields in the mojo uninitialized and then initialize the fields in the Starter using the constants which are now in the mojo?
I'm not sure if what I'm saying is really applicable though.

I would really appreciate if there would be at least a workaround how to get rid off those default values from the mojo (especially for the web app resources).
Frankly saying, isn't it better to set Jetty configuration the way how Jetty was designed than to forward several values, from the plugin config, using a temporary file (fork.props)?

Stepan

Actually, I've changed the name of the element to <resourceBases>. So now you do:

<resourceBases>
<resourceBase>/some/dir</resourceBase>
<resourceBase>/some/other/dir</resourceBase>
</resourceBases>

This brings the naming into line with that of the mvn jetty:run goal, where you can do:

<webApp>
<resourceBases>
<resourceBase>/some/dir</resourceBase>
<resourceBase>/some/other/dir</resourceBase>
</resourceBases>
</webApp>

Jan

Jan,
are you still considering whether to not override the context xml settings?
I'm not sure what the current status is.

I would like to know if I should find other solution (maven inherit plugin + jetty maven plugin).

Thanks,
Stepan

Hi Stepan,

Well, I still don't like the pom not being able to override the jetty config files, but ... I think its worthwhile making all the plugins behave consistently on this point, so I've changed the behaviour of jetty:run-forked so that the properties are applied first, and then the context xml. This means all plugins now effectively configure the WebAppContext from the pom first, and then apply any context xml file.

Jan

All mojos now work same way as per applying config : first from pom, then from any context xml files.