There is a probability that the Node plugin will be incompatible with Gradle 5.0.
The problem relates to a new dependency resolution behaviour that will be introduced in Gradle 5.0 (see Gradle documentation). Now if Gradle cannot find any metadata file (e.g. maven's *.pom or ivy.xml), it looks just for an artifact by its name. Such a behaviour is used in the Node.js plugin which downloads a Node distribution by declaring the distribution URL as a custom ivy-repository (source).
But since 5.0 Gradle will not look directly for an artifact by default. Thus the Gradle will not be able to resolve the dependency on Node.js distribution and the build will fail.
The easiest way to fix this is to use the metadataSources block as shown in Gradle documentation above (also see https://github.com/srs/gradle-node-plugin/pull/296). But such an API was introduced only in Gradle 4.5 so this change will make the plugin incompatible with older versions of Gradle.
So what do you think about this problem? Is the approach above appropriate or distribution downloading should be reworked in some other way?
Hello @srs!
There is a probability that the Node plugin will be incompatible with Gradle 5.0.
The problem relates to a new dependency resolution behaviour that will be introduced in Gradle 5.0 (see Gradle documentation). Now if Gradle cannot find any metadata file (e.g. maven's
*.pomorivy.xml), it looks just for an artifact by its name. Such a behaviour is used in the Node.js plugin which downloads a Node distribution by declaring the distribution URL as a custom ivy-repository (source).But since 5.0 Gradle will not look directly for an artifact by default. Thus the Gradle will not be able to resolve the dependency on Node.js distribution and the build will fail.
The easiest way to fix this is to use the
metadataSourcesblock as shown in Gradle documentation above (also see https://github.com/srs/gradle-node-plugin/pull/296). But such an API was introduced only in Gradle 4.5 so this change will make the plugin incompatible with older versions of Gradle.So what do you think about this problem? Is the approach above appropriate or distribution downloading should be reworked in some other way?