Gradle Plugins Version 1.3

LabKey Support Forum
Gradle Plugins Version 1.3 Susan Hert  2018-06-18 16:55
Status: Closed
 

With r58720 in trunk, the version of gradlePlugins has been updated to 1.3. As always, the full list of changes in this version are available in the README for the gradlePlugin repository. There are a couple of changes here that I wanted to call your attention to, one of which requires action from you for better success in building.

For the impatient, the summary is:

  • The build process will now download and use particular versions of npm and node. To avoid conflicts with node module versions, you need to remove any existing node_modules directories in the LabKey modules' enlistment directories before doing a build with the 1.3 gradlePlugin version. (If using npm from the command line, you should also update your path to reference the downloaded versions.)
  • Local builds will now fail if a conflict in version numbers is detected between two builds of a module (but you can change this behavior if you so desire).

Node and NPM

The build process will download the versions of npm and node that are specified by the properties npmVersion and nodeVersion, respectively, which are defined in the root-level gradle.properties file of the LabKey enlistment.

To avoid potential conflicts with node module versioning, you should remove any existing node_modules directories from your LabKey modules' directories before doing your first build with the 1.3 version. The 1.3 version of gradlePlugin provides a task, cleanNodeModules, that does just this. You can invoke this task at the root level of your enlistment and it will execute the task for all LabKey modules that have a package.json file. Alternatively, you can manually remove the node_module directory for each LabKey module that has one.

When running npm from the command line, you will want to be sure to use the version of npm that the gradle build uses. You can reference the versions for the core module in the <LABKEY_ROOT>/build/modules/core/.node/ directory.

On non-Windows platforms, the deployApp command creates symlinks for both node and npm in the directory .node at the root level of your enlistment:

trunk$ ls -la .node/
total 0
drwxr-xr-x   4 developer  staff   128 Jun 14 14:11 .
drwxr-xr-x  38 developer  staff  1216 Jun 18 10:36 ..
lrwxr-xr-x   1 developer  staff    90 Jun 14 14:11 node -> /Users/developer/Development/labkey/trunk/build/modules/core/.node/node-v8.11.3-darwin-x64
lrwxr-xr-x   1 developer  staff    77 Jun 14 13:58 npm -> /Users/developer/Development/labkey/trunk/build/modules/core/.node/npm-v5.6.0

If on Windows, you can create the symbolic links in the <LABKEY_ROOT>/.node directory manually to point to the node and npm versions in the core module's .node directory, as shown above. You should then put <LABKEY_ROOT>/.node/node/bin and <LABKEY_ROOT>/.node/npm/bin in your path.

If not using npm on the command line, the symbolic links and path changes are not necessary. (Note that the <LABKEY_ROOT>/.node directory won't exist until you run a deployApp command after updating to version 1.3.)

Local Build Version Discrepancies

With the 1.3 version, a feature that was incubating in the last release has now come out of incubation with a slight behavior change. You may have noticed if you did a build after someone updated a version of an external dependency that you would get a warning message something like this about version conflicts that would be produced by the build.

WARNING: Artifact versioning problem(s) in directory /Users/developer/Development/labkey/trunk/build/modules/api/explodedModule/lib:
  Conflicting version of commons-compress jar file (1.14 in directory vs. 1.16.1 from build).
  Conflicting version of objenesis jar file (1.0 in directory vs. 2.6 from build).

Now your build will fail if such version conflicts are detected (because the build would not be in a good state if both versions were included). If you need to, you can change that behavior by setting a value for the versionConflictAction parameter, as described in the Version Conflicts in Local Builds documentation.

 
 
Susan Hert responded:  2018-06-19 16:37

In order to fix a problem with the symbolic links for node and npm on the Windows platform, Version 1.3.1 of the gradle plugins has been released and the gradle.properties has been updated to reference that version in r58755 in trunk.

Making symbolic links on Windows does not work as well as on non-Windows platforms (requiring some specific permissions to do so and the use of other commands, not supported by Java classes currently), so the change with v1.3.1 is to simply not try to create the links on the Windows platform. For Windows users, I recommend that you remove the .node directory created in <LABKEY_ROOT>. The task that the 1.3 version introduced created that directory with some mysterious system files (node.sys and npm.sys, or something like that) that are nothing like symbolic links and would lead to errors like the following in subsequent builds:

> Task :server:symlinkNode FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':server:symlinkNode'.
> java.nio.file.NotLinkException: The file or directory is not a reparse point.

Removing the <LABKEY_ROOT>/.node directory will make this error go away and the directory should not be created again.

If running npm on the command line, it is still recommended that you put the versions of npm and node that the build is using on your path (That is, you can reference <LABKEY_ROOT>/build/modules/core/.node/node*/bin and <LABKEY_ROOT>/build/modules/core/.node/npm*/bin), but, at the moment, there's little benefit to using symbolic links for that on Windows as the links won't get updated when versions change.