Unpack node.js to local maven repo so it is reused after 'mvn clean'

[ghost]

Both our CI server and our developers often use mvn clean install to ensure the build is in a consistent state. As nodejs-maven-plugin unpacks the node.js binary to the project folder, this step is repeated each time even though most of the time the build uses the same node.js binary as the last build. This slows down builds considerably.

I propose that instead of defining <targetDirectory>, the plugin should allow an optional parameter that makes it download the node.js binary into the local maven repository, using a path that includes the version. The plugin could then store the path to the binary in a variable for use by other plugins.

This way, the plugin could simply skip the download step when the current release was already downloaded.

[skwakman]

Hi! From your post I understand the need for a higher build speed and preventing this plugin from always doing the same extract-operation would serve that purpose. I however don't like the idea of extracting files inside the local maven repository. I consider that the domain of Maven's dependency system, something individual plugins should not be performing operations on, outside of Maven's own API.

As an alternative we could introduce a new boolean parameter called overwrite. If set to false, it prevents the plugin from extracting files on a location where there's already a node binary present. This way, your build no longer has to wait for this plugin's extract operation if it has already been done earlier.

Would this solution work for you?

[bannmann]

(This is the same Jens; I switched to another account)

I understand your caution about putting stuff inside the maven repo.

However, your proposed alternative would not work. We do mvn clean install, so the target directory will be empty on each run. Also, our multi-module build contains two webapp projects, so it would still happen twice.

I came up with the maven repo as it is considered a long-term storage (even on our continuous integration server), and because the node.js binary, like the maven artifacts, is versioned, so there's no reason to unpack the same version again, ever.

I would propose researching/asking whether it is acceptable for maven plugins to write additional stuff inside the local repo.

If it really isn't, do this:

• add the overwrite parameter or change the plugin to never overwrite (because that isn't harmful even for the default case, at least if the node.js binary has a versioned name/subdirectory), and
• allow specifying a directory where to unpack the node binary (which could even default to ${project.build.directory} or whatever the variable for target is).
  This way, one could set this to ~\.whatever to achieve a similar effect than the maven repo.

[skwakman]

There already is a parameter which defines where the node binary is extracted. It's called targetDirectory, see the example configuration in the readme. It's default is currently set to ${project.build.outputDirectory}/nodejs.

So I guess with an added overwrite param it should fit your use case? If so, I've whipped up a snapshot version which includes the overwrite parameter. You can download it here. Source code is in this branch, this includes an updated configuration example.

I'd like to know if it works for you before I go through all the maven plugin publishing steps and make it a proper release.

[skwakman]

Have you checked the snapshot version?

[bannmann]

Yes, the overwrite parameter in combination with setting targetDirectory outside the project works fine. Please release that!

Note that I included the plugin version in the target directory name to make sure the binaries are overwritten when the plugin version changes (which may ship newer nodejs binaries).