Passthrough additional environment variables

[wherget]

This PR allows all Mojos to pass through additional environment variables to the build, accessible there through process.env.
This is a relatively quick and convenient way to transport (e.g.) Maven properties into the Node world, which is what I would be using it for.

<configuration>
    <environmentVariables>
        <OUTPUT_DIR>${project.build.directory}</OUTPUT_DIR>
    </environmentVariables> 
</configuration>

It would also fix #158.

[dantran]

+1

[achingbrain]

+1 This would be very useful.

[wherget]

I've ported this forward to current master. I'd really appreciate feedback.

[eirslett]

The advice I have given so far (in other issues buried deeeeeep down in the github issues list) is to pass on variables as flags:

<arguments>build --foo=${foo} --bar=${bar}</arguments>

and that might seem like a stupid solution at first, but it's actually pretty nice, since you can then run your frontend build independent of whatever you do in Maven. That's a huge win for frontend developers. You don't have to wait 3 minutes for the Java classes to compile and the unit tests to be run, in order to debug the gulp build.

[wherget]

I will (again) hold against that recommendation that it requires extreme care with quoting arguments. From what I read in NodeTaskExecutor.getArguments you're splitting at spaces. If I'm not severely mistaken, this breaks as soon as one of the ${foo} variables contains something with a space.

My use case would put an output directory there, which very well could contain spaces.

Secondly, relying on environment variables doesn't restrict independence of the build either:

FOO="/path/to directory/with space/" gulp build

works just the same from the command line.

[pope4e]

+1 I would appreciate this to be included also. I opted to the maven-exec-plugin for a current use case i am working on because of unavailability to tweak a bit the runtime environment variables here.

[pwielgolaski]

+1 I see real cases when I need to tweak som npm/boer configuration, not everything can be done by parameters

[eirslett]

Ok, let's get this merged in! :-)
@l337r007 I'm sorry, I've been so slow to look at this that it appears it has a merge conflict with master already... is it a big one?

[eirslett]

This was fixed in #346 :)