added eval of ${var} variables in config templates

[skyway777]

Now you can add ENV variables or another variables to config.
For example, you want to add build number to version.
You set BUILD_NUMBER to ENV variable, and then write into your config ${process.env.BUILD_NUMBER}

Now, version of config

var config = {
    "groupId"      : "com.example",    // required - the Maven group id.
    "artifactId"   : "{name}",         // the Maven artifact id.
    "buildDir"     : "dist",           // project build directory.
    "finalName"    : "{name}",         // the final name of the file created when the built project is packaged.
    "type"         : "war",            // type of package. "war" or "jar" supported.
    "fileEncoding" : "utf-8",          // file encoding when traversing the file system, default is UTF-8
    "generatePom"  : true,             // generate a POM based on the configuration
    "pomFile"      : "pom.xml",        // use this existing pom.xml instead of generating one (generatePom must be false)
    "version": "{version}.${process.env.BUILD_NUMBER}-${process.env.NODE_ENV}",
    "repositories" : [                 // array of repositories, each with id and url to a Maven repository.
      {
        "id": "example-internal-snapshot",
        "url": "http://mavenproxy.example.com/example-internal-snapshot/"
      },
      {
        "id": "example-internal-release",
        "url": "http://mavenproxy.example.com/example-internal-release/"
      }
    ]
};

will produce version: 1.0.1.234-production

[coveralls]

Coverage increased (+0.06%) to 98.077% when pulling ab5b1e9 on skyway777:master into 28c6979 on finn-no:master.

[micha149]

Why not simply using native template-strings?

For example:

const config = {
    // ...
    version: `{version}.${process.env.BUILD_NUMBER}-${process.env.NODE_ENV}`,
    // ...
};

[skyway777]

Because you cannot use this syntax in .json configs and cli-tools like https://github.com/wallaroo/maven-deploy-cli/blob/master/cli.js

[micha149]

I understand. But I have a bad feeling about using eval. On this way you could inject any code which is executed when someone wants to "deploy" a package.

What about something like:

const config = {
    // ...
    version: `{version}.{env(BUILD_NUMBER)}-{env(NODE_ENV)}`,
    // ...
};

So, we can parse the content in curly braces. if its something like env\((.+)\) we pick it from process.env. For backwards compatibility other strings are resolved via package.json.

[skyway777]

Looks good. I will change my PR that way.

[micha149]

Alternatively we may use something like mustache or lodash.template for supporting variables in config strings. So, we could have full control over the context and adding more data would be easy.

A proper context could look like:

const context = {
    ... pkg, // merge values from package.json for backwards compatibility
    package,
    env: process.env
};

// ...

const config = {
    // ...
    version: '{{package.version}}.{{env.BUILD_NUMBER}}-{{env.NODE_ENV}}'
    // ...
}

With this solution we dont't need to implement an own templating system…

[skyway777]

Added mustache in my last commit.

[ankon]

Style: spaces around '+' and ',' are missing.

[ankon]

Ditto here.

[ankon]

Style: Quoting of finalName is unneeded, and doesn't match the rest of the area.

[micha149]

@skyway777 have you tested if single curly braces could work with mustache? Maybe we could remove the old replacing mechanism entirely?!

[skyway777]

No, it doesn't support single curly braces...