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:
Node and NPMThe 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 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
If on Windows, you can create the symbolic links in the If not using npm on the command line, the symbolic links and path changes are not necessary. (Note that the Local Build Version DiscrepanciesWith 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.
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. |
||