我们有一种情况,我们在运行 gradle 的 VM 中占用了一个 Jetty 实例。
但是,当我们在 gradle 守护进程中运行时,这会非常失败:我们并没有完全摆脱 Jetty 实例,因此它必须随着 gradle 进程本身而死。(但是,这并不是什么大问题,因为无论如何我们都不希望在这个 CI 集成测试案例中使用 gradle 守护进程)。
因此,我们想知道当前任务是否在 gradle 守护进程中运行,以便我们可以抛出异常或以其他方式通知用户这是错误的方法,请运行此未守护进程。
我们有一种情况,我们在运行 gradle 的 VM 中占用了一个 Jetty 实例。
但是,当我们在 gradle 守护进程中运行时,这会非常失败:我们并没有完全摆脱 Jetty 实例,因此它必须随着 gradle 进程本身而死。(但是,这并不是什么大问题,因为无论如何我们都不希望在这个 CI 集成测试案例中使用 gradle 守护进程)。
因此,我们想知道当前任务是否在 gradle 守护进程中运行,以便我们可以抛出异常或以其他方式通知用户这是错误的方法,请运行此未守护进程。
Gradle 将其线程之一命名为“守护线程”,因此如果您允许 hack,这可能会起作用:
def isDaemon = Thread.allStackTraces.keySet.any { it.name.contains "Daemon" };
另一种解决方案是读取“sun.java.command”属性。
如果您在守护进程中,则 gradle 2.5 的值为
org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.5
如果你不是,价值是
org.gradle.launcher.GradleMain taskName
这么简单
if (System.properties.'sun.java.command'.contains('launcher.daemon')) {
println 'Daemon is true'
} else {
println 'Daemon is false'
}
也会成功的
我想从 gradle 插件的上下文中了解这一点。在检查了 gradle 源之后,我最终使用以下方法找到了答案:
val daemonScanInfo: DaemonScanInfo? = (project as DefaultProject).services.get(DaemonScanInfo::class.java)
val runningAsDaemon = !daemonScanInfo.isSingleUse
这具有能够检测--no-daemon
和定义的好处org.gradle.daemon=true|false
。这样project.findProperty("org.gradle.jvmargs")
做没有在命令行上捕获 --no-daemon 。