System properties are not getting cleared out between runs within an aggregator

Martin,

Is this an issue with maven poms? Perhaps it is best to raise the issue with Maven?

If you think it is a Jetty issue, can you give us more information and perhaps an example?

cheers

Greg,

This is an issue with the Jetty plugin, not with the properties defined in the pom. It's not a Maven problem per se. It's a problem with the plugin's handling of system properties.
I removed all the systemProperties defined in the Jetty plugin. I then knocked up a simple Maven plugin, which sets system properties. With my plugin, the system properties are cleared between runs of the Jetty plugin in a multi-module aggregator which has more that one module running Jetty tests. (You can find my plugin here: https://github.com/carlspring/system-properties-maven-plugin ).

Also, the plugin doesn't set system properties which have already been set. This is kind of a limitation.
I worked around this problem by not using the <systemProperties> setting in the Jetty plugin and defining these properties in my plugin, but that should not be the way things work. In my opinion, the Jetty plugin should be able to override system properties and to make sure <systemProperties> are only defined for the scope of the execution.

Martin,

I agree this is jetty plugin behaviour. I remember implementing the setting this way purposefully, but I can't remember why. I agree that we should change it.

Jan

Yeah, I actually had a look at the sources and I was struck by the fact that there is a specific if statement which checks if a system property has already been set and skips setting a new value. That's why I knocked up my workaround plugin. I tried looking around the code for comments explaining this behavior, but since I couldn't find any I decided to file a bug report as it's not exactly expected behavior.

There could, for example, be a boolean configuration property which tells the Jetty plugin to not set new values for already defined system property. In my opinion, if such a property is introduced, it should actually default to false.

Ah, I remembered why I did it. You need to be able to have the command line override the System properties that might be set in the pom/programmatically.

Jan

The more I think about this, the less inclined I am to change the current behaviour. Consider that the SystemProperties are set as the plugin begins to execute. Any clear-down of them could not reasonably be done until jetty stops running. At that point, if we start changing the system properties, we may change the exit behaviour. For example, if a system property was set that affected the logging, perhaps resetting that would mean that an exception thrown on exit would not be logged (to the same logging framework used for the rest of the runtime).

Instead of using <systemProperties> you could instead set your system properties in jetty.xml files that are executed with each new plugin invocation - they have normal jvm semantics and thus you can set them over and over again as suits your application.

Jan

Jan, when you said you can "set your system properties in jetty.xml files"... did you mean with a System.call invocation like what is described here (http://stackoverflow.com/a/4735302/255830) or is there a cleaner solution?

Yes, it would be something like that.

Fixed.

To have the system properties specified in the pom override those on the command line use <force>true</force>. Eg:

 <systemProperties>
    <force>true</force>
    <systemProperty>
       <name>fooprop</name>
       <value>222</value>
     </systemProperty>
  </systemProperties>