Support Gradle 6.0

[deepy]

Current issue (srs/gradle-node-plugin#316)

The IvyArtifactRepository.layout(String, Closure) method is scheduled to be removed in Gradle 6.0.
IvyArtifactRepository.patternLayout(Action) which replaces it is still incubating

The IvyArtifactRepository.layout(String, Closure) method has been deprecated. This is scheduled to be removed in Gradle 6.0. Please use the IvyArtifactRepository.patternLayout(Action) method instead.

Old context (srs/gradle-node-plugin#299)

(importing an issue that is dear to me srs/gradle-node-plugin#299)
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 #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?

[pioorg]

There might be more... When I build wtih Gradle 4.10.3, in the console output I see

Registering invalid inputs and outputs via TaskInputs and TaskOutputs methods has been deprecated. This is scheduled to be removed in Gradle 5.0. A problem was found with the configuration of task ':ui:npmInstall'.
 - File '/I/had/to/skip/full/path/node_modules/package.json' specified for property '$1' does not exist.

Maybe the fix is as simple as in joelittlejohn/jsonschema2pojo#809?

[atomfrede]

Hi @deepy thanks for stepping up and maintaining a fork of this plugin 🥇 !

I maintain the gradle build of jhipster (https://www.jhipster.tech/) and will soon update to gradle 5.1 and try your fork instead of the original plugin (as there is not other viable alternative with the same rich feature set right now). So if I find more problems/incompatibilities I will post them here and try to provide PRs if you are ok with that. So when we have migrated to your fork be prepared for much more downloads and maybe more issues 🎉

[deepy]

@atomfrede do you know if there's anyone from jhipster who'd be interested and suitable for commit access?
There are going to be times when I have less time to work on things and it'd be great to have some more redundancy

[atomfrede]

@deepy I am the stream lead of our gradle support, so I could do it maybe. We have updated the plugin for the upcoming 6.x release scheduled for ~spring/summer. But I have not much experience with writing large scale gradle plugins so. What is your roadmap for the plugin, especially how to handle gradle 6 deprecations?

BTW I will be on the javaland conference and planning to talk to some of the graldle developer advocates and maybe do some coding, so if you have something in mind let me know and I will try to handle it with help from them.

[cdietrich]

see also srs/gradle-node-plugin#316

[deepy]

I guess we could replace the current fix or add another conditional since the new method came in 5.0 and it'd be great to keep backwards compatibility as long as possible (without it becoming a burden)

@atomfrede The current roadmap is probably the following and likely in this order: #7 (Gradle 6 compatible support for npm ci instead of npm install), add an option to disable the default task dependencies, and then probably going through the issues posted at srs/gradle-node-plugin and see which others need to be fixed.
This issue (#2) will probably be done the moment someone explicitly asks for this support to be included or when there's a rc of Gradle 6

[deepy]

Oh and for javaland, any help with #7 would be awesome, I have a PR with a proposed solution but I'm not entirely happy with some of the drawbacks of it (especially that running npmCi alone won't be enough in that case)

[atomfrede]

I would propose to have gradle 5 as baseline, as it will be less maintenance burden on everyone involved.

[deepy]

Having done some internal surveys where I work and seeing how prominent gradle 3 and 4 is I'd like to propose latest gradle 4 as baseline for the next 3 months and then switching to Gradle 5 as we bump the version to 2.0 and ditch grunt/gulp #12 (while also giving them some time to be marked as deprecated in 1.x)