Kotlin via a Gradle build script isn't executing a WebDriver spek - gradle

Repo with a tight reproduction of my problem: https://github.com/paul-hammant/kotlin-webdriver-snafu
The spec, that could not be simpler:
class WebDriverSpeks : Spek({
ChromeDriverManager.getInstance().setup()
val co = ChromeOptions()
val chromeDriver = ChromeDriver(co) as WebDriver
beforeGroup {
chromeDriver.get("https://yahoo.com/")
}
describe("yahoo") {
it("should have index.html") {
assertEquals(chromeDriver.title, "hello")
}
}
afterGroup {
chromeDriver.close()
}
})
There's no red lines denoting compile failures in Intellij, yet when the gradle build runs it complains about a transitive dep:
$ gradle build
Download https://jcenter.bintray.com/org/slf4j/slf4j-api/1.7.24/slf4j- api-1.7.24.jar
w: Runtime JAR files in the classpath should have the same version. These files were found in the classpath:
/Users/paul/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.2.30/f916048adc012c9342b796a5f84c0ac6205abcac/kotlin-stdlib-jdk8-1.2.30.jar (version 1.2)
/Users/paul/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.2.30/ca12c47fc1e3a7316067b2a51e2f214745ebf8c5/kotlin-stdlib-jdk7-1.2.30.jar (version 1.2)
/Users/paul/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.0.6/3d499d3b7768f88c4796e5a1e357933e11a8936d/kotlin-reflect-1.0.6.jar (version 1.0)
/Users/paul/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.2.30/2dfac33f8b4e92c9dd1422cd286834701a6f6d6/kotlin-stdlib-1.2.30.jar (version 1.2)
w: Consider providing an explicit dependency on kotlin-reflect 1.2 to prevent strange errors
w: Some runtime JAR files in the classpath have an incompatible version. Consider removing them from the classpath or use '-Xskip-runtime-version-check' to suppress this warning
e: Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
class org.openqa.selenium.chrome.ChromeDriver, unresolved supertypes: org.openqa.selenium.remote.RemoteWebDriver
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileTestKotlin'.
> Compilation error. See log for more details
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 6s
5 actionable tasks: 5 executed
The allegedly unresolved supertype org.openqa.selenium.remote.RemoteWebDriver is in a selenium-remote-driver, and
If I delete ~/.gradle or ./build and try again it is the same.
If I inspect the pom.xml for selenium-java, I can see a dependency on selenium-remote-driver (which exists). See here - http://central.maven.org/maven2/org/seleniumhq/selenium/selenium-java/3.11.0/selenium-java-3.11.0.pom. The one in jcenter is the same.
I don't know why Gradle isn't finding selenium-remote-driver. I have an extra testCompile commented out in the Gradle script but nothing gets fixed if it is commented in.
I think this is a problem in Gradle, or some Gradleized treatment of Maven Central that I don't know much about but is online somewhere. I don't think it is a Kotlin problem. I've used Selenium since it started and am super familiar with it (I've made 100 Maven projects that use Selenium) so I don't think that is it. Of course, I could be wrong with where the root cause is.

Well, this did the trick:
rm -rf ~/.m2/repository/org/seleniumhq/
I didn't know Gradle used the local Maven repo cache. It must have been corrupt somehow.
Hopefully this helps someone another day.

Related

Why gradle 7.3 is incapable of finding a submodule defined using relative path?

I have a gradle project with 1 submodule, defined in the following file structure (+- refers to a directory):
+- <root>
build.gradle.kts
+- graph-commons
+- core
build.gradle.kts
The only submodule was included using the following kotlin script:
val graphCommons = project(File("./graph-commons/core"))
includeBuild(graphCommons)
When I execute ./gradlew clean assembly, I got the following error:
FAILURE: Build failed with an exception.
* Where:
Settings file '/home/peng/git/shapesafe/settings.gradle.kts' line: 2
* What went wrong:
Project with path './graph-commons/core' could not be found.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 492ms
FAILURE: Build failed with an exception.
* Where:
Settings file '/home/peng/git/shapesafe/settings.gradle.kts' line: 2
* What went wrong:
Project with path './graph-commons/core' could not be found.
What went wrong? Why the valid path "./graph-commons/core" cannot be identified by gradle?
The project is uploaded and tested on github:
https://github.com/tribbloid/shapesafe/runs/4280805005?check_suite_focus=true
Gradle does not work this way. A project path refers to a gradle project path, not to a file path. See https://docs.gradle.org/current/userguide/multi_project_builds.html#multi_project_builds
Edit: As mentioned in the comments, the project(File) method that is available in the settings.gradle.kts is a special method allowing to receive a ProjectDescriptor whose directory points to the given file. The project must be present already e.g. by including it via include(String...) first.
I first thought you tried to use the DependencyHandler#project(Map) method in some way, which is the usual way to refer to project dependencies. Gradle separates between dependencies and multi-project setup. In the settings.gradle.kts you usually setup the project structure while you declare dependencies in each build.gradle.kts. When using includeBuild you merely depend on the build of another completely separate project. When you then want to declare a dependency to a project from that included build you usually use the project's artifact coordinates to do so. This way the build still works when removing the includeBuild declaration.
If you want to use composite builds see here for basic usage: https://docs.gradle.org/current/samples/sample_composite_builds_basics.html
You will have to coordinate the artifact publishing and corresponding dependencies to make it work like a normal multi-project. Something like this:
graph-commons
|build.gradle.kts -> group = "org.scala-lang"; version = "1.0";
|settings.gradle.kts -> include(":graph-commons-core")
|graph-commons-core
||build.gradle.kts
shapesafe
|settings.gradle.kts -> includeBuild("../graph-commons")
|core
||build.gradle.kts -> dependencies { implementation("org.scala-lang:graph-commons-core:1.0") }

Gradle upgrade 7.2 > 7.3 breaks with "The value for this property is final and cannot be changed any further" (with Micronaut plugin?)

I'm using Micronaut 3.1.3 together with Gradle 7.2 to build my project.
After switching to Gradle 7.3, built breaks emitting some context-free error message:
$ ./gradlew clean build
Executed by Gradle 7.3
- using Java 11.0.13
- using Kotlin 1.5.31
- using Groovy 3.0.9
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project '[PROJECT]'.
> The value for this property is final and cannot be changed any further.
With --stacktrace a very long trace appears. The following excerpt makes me guess
that the problem might lay in the Micronaut plugin:
* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring root project '[PROJECT]'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.wrapException(LifecycleProjectEvaluator.java:75)
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:68)
at org.gradle.configuration.project.LifecycleProjectEvaluator.access$400(LifecycleProjectEvaluator.java:51)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: java.lang.IllegalStateException: The value for this property is final and cannot be changed any further.
at org.gradle.api.internal.provider.AbstractProperty$FinalizedValue.beforeMutate(AbstractProperty.java:489)
at org.gradle.api.internal.provider.AbstractProperty.assertCanMutate(AbstractProperty.java:263)
at org.gradle.api.internal.provider.AbstractProperty.setSupplier(AbstractProperty.java:212)
at org.gradle.api.internal.provider.DefaultProperty.set(DefaultProperty.java:71)
at org.gradle.api.tasks.testing.Test.useTestFramework(Test.java:979)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1049)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1032)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$null$1(MicronautLibraryPlugin.java:103)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.api.internal.DefaultDomainObjectCollection.withType(DefaultDomainObjectCollection.java:201)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$apply$4(MicronautLibraryPlugin.java:101)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Cause "problem occurred configuring root project" I'm not sure which part of my
build.gradle raises the problem. So following my first guess regarding Micronaut
plugin, here is an excerpt telling you the list of plugins in use and config of this plugin:
plugins {
id('org.jetbrains.kotlin.jvm') version "${kotlinVersion}"
id('groovy')
id('org.jetbrains.kotlin.kapt') version "${kotlinVersion}"
id('com.github.johnrengelman.shadow') version '7.+'
id('io.micronaut.application') version '2.+'
id('org.jetbrains.kotlin.plugin.allopen') version "${kotlinVersion}"
id('com.google.cloud.tools.jib') version '3.+'
id('org.openapi.generator') version '5.+'
id('com.heroku.sdk.heroku-gradle') version '2.+'
}
[...]
micronaut {
runtime('netty')
testRuntime('spock2')
processing {
incremental(true)
annotations('[PACKAGE]')
}
}
Maybe this gives enough information to tackle down the cause of the problem?
If not please let me know.
Regards
I hit the same issue with my Java build and asked for help on gradle slack channel. It found to be a change in Gradle 7.3 behavior.
This issue contains an explanation of the cause and how to fix it.
It helped me to solve the issue with my build: I had options defined in one of the test tasks and then useJUnitPlatform was applied across all test tasks afterwards using this snippet:
tasks.withType(Test).configureEach {
useJUnitPlatform() // <-- this line was breaking the build
}
This broke the build after migrating to Gradle 7.3. Removing options solved the problem for me.
Here's an issue requesting to convert this breaking behavior to a warning in Gradle 7.3 and make it a breaking change in 8.0.
FYI: Upgrade to Gradle 7.3.1 brings back successful builds.

Gradle 7.2 Tar task baseName deprecated but replacement archiveBaseName is rejected

I have started using Gradle 7.2 to build a project that produces a compressed Tar archive. Gradle is issuing a deprecation warning that baseName is deprecated and should be replaced with archiveBaseName. But it rejects archiveBaseName.
A very much simplified example using a trivial Gradle build script, with their associated execution outputs are given below. I did run 'gradle --stop' to ensure a prior version's daemon wasn't actually executing; a GRADLE_HOME environment variable is pointing to the correct Gradle folder (not sure it's needed, but it is set.)
I tried using "archiveBaseName" both without and with "=" ("archiveBaseName 'Test'" and "archiveBaseName='Test'").
The docs seem to suggest archiveBaseName should already be available, so I don't think it's just a heads up of things to come.
Thank you!
Gradle file:
task dist(type: Tar) {
baseName 'Test'
into ('.') { from('.') }
}
Execution:
gradle build --warning-mode=all
c:\jdev\newpaas\xxx>gradle build --warning-mode all
> Configure project :
The AbstractArchiveTask.baseName property has been deprecated. This is scheduled to be removed in Gradle 8.0. Please use the archiveBaseName property instead. See https://docs.gradle.org/7.2/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.html#org.gradle.api.tasks.bundling.AbstractArchiveTask:baseName for more details.
at build_2qa2gx0itzunotwyc4ndf9v86$_run_closure1.doCall(C:\jdev\newpaas\xxx\build.gradle:2)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
> Task :buildEnvironment
------------------------------------------------------------
Root project 'TestProject'
------------------------------------------------------------
classpath
No dependencies
A web-based, searchable dependency report is available by adding the --scan option.
BUILD SUCCESSFUL in 983ms
1 actionable task: 1 executed
Gradle file:
task dist(type: Tar) {
archiveBaseName 'Test'
into ('.') { from('.') }
}
Execution:
c:\jdev\newpaas\xxx>gradle build --warning-mode all
FAILURE: Build failed with an exception.
* Where:
Build file 'C:\jdev\newpaas\xxx\build.gradle' line: 2
* What went wrong:
A problem occurred evaluating root project 'TestProject'.
> Could not find method archiveBaseName() for arguments [Test] on task ':dist' of type org.gradle.api.tasks.bundling.Tar.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
Gradle file:
task dist(type: Tar) {
archiveBaseName='Test'
into ('.') { from('.') }
}
Execution:
c:\jdev\newpaas\xxx>gradle dist
> Task :dist FAILED
FAILURE: Build failed with an exception.
* What went wrong:
A problem was found with the configuration of task ':dist' (type 'Tar').
- Type 'org.gradle.api.tasks.bundling.Tar' property 'archiveFile' doesn't have a configured value.
Reason: This property isn't marked as optional and no value has been configured.
Possible solutions:
1. Assign a value to 'archiveFile'.
2. Mark property 'archiveFile' as optional.
Please refer to https://docs.gradle.org/7.2/userguide/validation_problems.html#value_not_set for more details about this problem.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
1 actionable task: 1 executed
I stumbled across this syntax and it seems to be working for me:
archiveFileName = "${archiveBaseName}-${archiveVersion}.${archiveExtension}"

how do I add JavaFX to a gradle build file using Kotlin DSL?

how do I add the javafx dependencies through gradle?
thufir#dur:~/NetBeansProjects/helloWorldJavaFX$
thufir#dur:~/NetBeansProjects/helloWorldJavaFX$ gradle clean
> Configure project :
e: /home/thufir/NetBeansProjects/helloWorldJavaFX/build.gradle.kts:13:7: Unresolved reference: openjfx
FAILURE: Build failed with an exception.
* Where:
Build file '/home/thufir/NetBeansProjects/helloWorldJavaFX/build.gradle.kts' line: 13
* What went wrong:
Script compilation error:
Line 13: org.openjfx.javafxplugin
^ Unresolved reference: openjfx
1 error
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
thufir#dur:~/NetBeansProjects/helloWorldJavaFX$
the manual says:
plugins {
id 'application'
id 'org.openjfx.javafxplugin' version '0.0.7'
}
my build file has:
plugins {
// Apply the java plugin to add support for Java
java
org.openjfx.javafxplugin
// Apply the application plugin to add support for building an application
application
}
which is generating the above error.
in the plugins-section you have to put
id("org.openjfx.javafxplugin") version "0.0.8"
instead of just org.openjfx.javafxplugin.
After that you can put a javafx-section like
javafx {
modules("javafx.controls", "javafx.fxml")
}
somewhere (I prefere to put it next to the dependency-section). Here you can put in any module you need.
For further configuration posibilities have a look JavaFX Gradle Plugin.

Specifying multiple dependencies in gradle file

Based on references below:
https://www.petrikainulainen.net/programming/gradle/getting-started-with-gradle-dependency-management/
I believe I can specify multiple dependencies under a dependency configuration like below:
However, when I try to run gradle build, I see the following errors.
Is this not the right way to provide multiple dependencies in a gradle file?
D:\TestGradle>gradle build
FAILURE: Build failed with an exception.
* Where:
Build file 'D:\TestGradle\build-ProblemTemplate.gradle' line: 116
* What went wrong:
Could not compile build file 'D:\TestGradle\build-ProblemTemplate.gradle'.
> startup failed:
build file 'D:\TestGradle\build-ProblemTemplate.gradle': 116: expecting ')', found ',' # line 116, column 68.
toolVersions.mockitoVersion}'],
^
1 error
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
D:\TestGradle>
Also tried removing the [] in the testCompile configuration as mentioned in answer from Jakub Wójcik below. But still get the same error.
Update
Surprisingly, removing the line break after dependency configuration name worked for me.
It worked fine with or with out [] brackets. Still don't know why this matters, but updating the thread with my findings so far.
You can try specifying the dependencies with the configuration for each one of them. I think this is most common and used way.
dependencies {
compile 'dep1'
compile 'dep2'
}
or if you really want to just pass in a comma-separated args to compile closure.
dependencies {
compile (
'dep1',
'dep2'
)
}
PS. When using $variables you need to use the GString " (double quotes).
PPS. You can pass a vararg or an array to the configuration it doesn't really matter.
For the new lines
Gradle uses groovy for its scripts and this is not a bug its intentional actually, because () or {} may be interpreted as a separate block for the compiler. Refer to Context-sensitive_grammar
Its all to Groovy parser at the end of the day :)
Try removing the [] brackets, when having multiple dependencies for a testCompile clause. Also, note that you have an extra " in the line 118.

Resources