gradle-node-plugin
gradle-node-plugin copied to clipboard
Support BSD and platforms without official node.js binaries (with download = false)
It seems that the only place were OpenBSD support would need to be added is at PlatformHelper.kt
If you would add
name.contains("openbsd") -> "linux"
And also (for completeness)
name.contains("netbsd") -> "linux"
name.contains("dragonflybsd") -> "linux"
I thought OpenBSD removed the Linux emulation.
But while I wish we could support it, unless you're fetching someone else's builds that change will only mean that the Linux node will be downloaded and the build will fail.
The linux you mention is what decides what to download from here https://nodejs.org/dist/v16.4.0/.
Though with that said, if you pkg_add node then the download = false should work fine on BSD.
Indeed, I am using dowload = false. But the error of unsupported OS still comes up.
As you noted, npm node openjdk11 are all native tools on OpenBSD (and the other BSDs).
In my setup, I have all of them already installed and working (using pkg_add binary package manager). So no downloads of node or npm tools are required.
buildscript {
repositories {
mavenCentral()
maven {
url 'https://plugins.gradle.org/m2/'
}
}
dependencies {
//note the 'unsupported os' on openbsd error happens with the latest 3.0.1 plugin release as well
classpath 'com.moowork.gradle:gradle-node-plugin:1.3.1'
}
}
apply plugin: 'base'
apply plugin: 'com.moowork.node'
node {
download = false
}
npm_run_obuild {
change
inputs.files fileTree('public')
inputs.files fileTree('src')
inputs.file 'package.json'
inputs.file 'package-lock.json'
inputs.file 'postcss.config.js'
outputs.dir 'build'
}
// pack output of the build into JAR file
task packageNpmApp(type: Zip) {
dependsOn npm_run_obuild
//baseName 'mx2'
archiveBaseName.set('mx2')
extension 'jar'
destinationDir file("${projectDir}/build_package_mx2")
from('build') {
into "mx2_site"
}
}
// declare a dedicated scope for publishing the packaged JAR
configurations {
npmResources
}
configurations.default.extendsFrom(configurations.npmResources)
// expose the artifact created by the packaging task
artifacts {
npmResources(packageNpmApp.archiveFile) {
builtBy packageNpmApp
type 'jar'
}
}
assemble.dependsOn packageNpmApp
String testsExecutedMarkerName = "${projectDir}/.tests.executed"
task test(type: NpmTask) {
dependsOn assemble
environment CI: 'true'
args = ['run', 'test']
inputs.files fileTree('src')
inputs.file 'package.json'
inputs.file 'package-lock.json'
// allows easy triggering re-tests
doLast {
new File(testsExecutedMarkerName).text = 'delete this file to force re-execution
}
outputs.file testsExecutedMarkerName
}
check.dependsOn test
clean {
delete packageNpmApp.archivePath
delete testsExecutedMarkerName
}
Oooh that is a bug then, I don't the error should be appearing at all with download = false
My initial reason for starting to look into the code of this plugin was actually to get FreeBSD supported. I have to walk my dog now but I think I can have this done during weekend, BSD is dear to me
thank you!. Just an FYI For openBSD the whole toolchain gradle/nodejs/npm works well, so you you can check the issue there (or I can do a fix test, if you would like, I am running obsd 6.9-amd64).
However, you will, likely, not be able to test this on netBSD -- because gradle does not work there, at all, with openjdk11 (works with jdk-8). There is an outstanding issue for that in netBSD tracker, but it had not been resolved yet.
The implementation of this got a bit messy and there's a bunch of things that need to be fixed to do this properly, but I've started a WIP PR at #179
It's tested the PR on FreeBSD and with download = false it works fine, but with download = true there's a bunch of weird errors appearing in unexpected places, so we need to do some more work before it can be merged.
So on one hand, I think we can (in the future) support download = true and just having the download tasks fail during runtime (which is preferred, since you're not guaranteed to run the tasks)
But on the other hand, right now that means a bunch of paths get messed up and there's failures at runtime.
now to get some progress on this I left it at failing when the plugin is applied and download = true