Maven 2.x Exec Plugin

-D commandline properties no longer passed through in SystemProperties in exec:java

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1-beta-1
  • Fix Version/s: 1.1
  • Component/s: None
  • Labels:
    None
  • Environment:
    using maven-core from the tip of the 2.0.x branch (ie, the as-yet-unreleased 2.0.9)
  • Number of attachments :
    0

Description

My patch for MNG-2848 included removing System.setProperty( name, value ) for properties passed in with -D commandLine arguments (since the comment implied that wasn't necessary).

Unfortunately, that means that any properties passed in with -D on the commandline are no longer passed in as SystemProperties in exec:java.

I'd argue that it was happy coincidence that this ever worked, as plugins shouldn't really be accessing commandline properties through the SystemProperties, however it's far too useful a feature to drop.

I see a couple of possibilities:

1) Reinstate System.setProperty for all properties passed on the commandline. This would be quick and reliable, but seems somehow wrong given its only exec:java which would be making use of it.

2) Add all the properties in context.getExecutionProperties() to the SystemProperties before running exec:java. This fits in better with the maven API, but would mean that suddenly every property defined in the pom, plus a load of env.foo properties for the environment, would get passed through to the subprocess.

Any thoughts?

Activity

Hide
Brian Fox added a comment -

The change for MNG-2848 to remove the system properties should be reverted (i think it already has). This can affect other things like when maven forks another maven build etc.

Show
Brian Fox added a comment - The change for MNG-2848 to remove the system properties should be reverted (i think it already has). This can affect other things like when maven forks another maven build etc.
Hide
John Casey added a comment -

Looks like Vincent S. rolled back the removal of the System property setting in Maven Cli. This is appropriate IMO, since we don't always have control over what the arbirary code to be executed will expect. It may be that we don't have the ability to get away from system properties, even though it may mean that we can't safely handle these types of executions in a multi-threaded environment.

Show
John Casey added a comment - Looks like Vincent S. rolled back the removal of the System property setting in Maven Cli. This is appropriate IMO, since we don't always have control over what the arbirary code to be executed will expect. It may be that we don't have the ability to get away from system properties, even though it may mean that we can't safely handle these types of executions in a multi-threaded environment.

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: