I had done a simple project, trying to understand how ParameterizedTest and ValueSource works.
From the below picture it finds the import path, but it throws an error when I try to run the code:
Also the gradle file:
Here is a link to the entire project.
You need to put junit-jupiter-params in the testCompile source set.
junit-jupiter-params exports types like #ParameterizedTest and #ValueSource that are needed at compile (and run~) time.
See also: Missing org.junit.jupiter.params from JUnit5
Starting with version 5.4.0-M1 JUnit Jupiter provides an aggregator artifact that bundles all available Jupiter-defining artifacts for easy consumption. See https://sormuras.github.io/blog/2018-12-26-junit-jupiter-aggregator.html for details.
Related
This follows on from this excellent solution to the question of how to get Gradle to bundle up JavaFX with your distributions.
NB specs: Linux Mint 18.3, Java 11, JavaFX 13.
That stuff, involving jlink and a module-info.java, is beyond my pay grade (although I'm trying to read up on these things).
I want to move to using Groovy in my app and test code (i.e. Spock) rather than Java. The trouble is, the minute I include the "normal" dependency in my build.gradle i.e.
implementation 'org.codehaus.groovy:groovy-all:2.5.9'
and try to build, I get multiple errors:
mike#M17A ~/IdeaProjects/TestProj $ ./gradlew build
> Configure project :
Found module name 'javafx.jlink.example.main'
> Task :compileTestJava FAILED
error: the unnamed module reads package org.codehaus.groovy.tools.shell.util from both org.codehaus.groovy.groovysh and org.codehaus.groovy
[...]
error: the unnamed module reads package groovy.xml from both org.codehaus.groovy and org.codehaus.groovy.xml
[...]
error: module org.codehaus.groovy.ant reads package groovy.lang from both org.codehaus.groovy and org.codehaus.groovy.test
error: module org.codehaus.groovy.ant reads package groovy.util from both org.codehaus.groovy.xml and org.codehaus.groovy.ant
100 errors
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileTestJava'.
Yes, 100 errors... probably more! By commenting out various things I think I've come to the conclusion that some Groovy dependency is being injected by the jlink stuff. Fine, I can live with that (although it'd be nice to know what version of Groovy it is).
The trouble is, even if I omit the Groovy dependency line, the same errors occur when I try to introduce the Spock dependency:
testImplementation 'org.spockframework:spock-core:1.2-groovy-2.5'
Has anyone got any idea what's going on here and what to do about it?
I searched for an answer. I didn't find a good solution.
According to this, it seems that Groovy is currently not really compatible with Java modules. It is due to the fact that some packages are contained by multiple jars of the library (not compatible with modules). You will have to wait for Groovy 4 for a compatible version.
I discovered that the JavaFX plugin use this plugin internally. This plugin seems to consider that all dependencies are modules (it is not the default Gradle behaviour).
To make your application works, it seems that you have to:
force Gradle to put Groovy in the classpath instead of the modulepath (it will not be considerered as a module, but seems impossible if you use the javafx plugin)
use the "patch-module" system: it allows Gradle to make a fusion of the library jars into a single module, to prevent the problem of packages that are in different jars
I searched the Groovy jars with IDEA (Project structure/Libraries), and I tried to use the syntax offered by the plugin to use "patch-module":
patchModules.config = [
"org.codehaus.groovy=groovy-ant-3.0.1.jar",
"org.codehaus.groovy=groovy-cli-picocli-3.0.1.jar",
"org.codehaus.groovy=groovy-console-3.0.1.jar",
"org.codehaus.groovy=groovy-datetime-3.0.1.jar",
"org.codehaus.groovy=groovy-docgenerator-3.0.1.jar",
"org.codehaus.groovy=groovy-groovydoc-3.0.1.jar",
"org.codehaus.groovy=groovy-groovysh-3.0.1.jar",
"org.codehaus.groovy=groovy-jmx-3.0.1.jar",
"org.codehaus.groovy=groovy-json-3.0.1.jar",
"org.codehaus.groovy=groovy-jsr-3.0.1.jar",
"org.codehaus.groovy=groovy-macro-3.0.1.jar",
"org.codehaus.groovy=groovy-nio-3.0.1.jar",
"org.codehaus.groovy=groovy-servlet-3.0.1.jar",
"org.codehaus.groovy=groovy-sql-3.0.1.jar",
"org.codehaus.groovy=groovy-swing-3.0.1.jar",
"org.codehaus.groovy=groovy-templates-3.0.1.jar",
"org.codehaus.groovy=groovy-test-junit-3.0.1.jar",
"org.codehaus.groovy=groovy-test-3.0.1.jar",
"org.codehaus.groovy=groovy-testng-3.0.1.jar",
"org.codehaus.groovy=groovy-xml-3.0.1.jar"
]
It only works with a single line "org.codehaus.groovy=X.jar", but a bug prevents it to work with all of the library jars (Look at this issue on Github).
So you have multiple choices:
Use Java instead of Groovy
Wait for a new Groovy release, or new releases of plugins (modules-plugin, and a version of javafx-plugin that use this one internally)
Use old javafx configuration: dependencies are not module by default, and you have to specify manually in build.gradle that JavaFX dependencies should be considered as a module (check my "obsolete" answer to this question)
I have a gradle project (converted from an original ANT project). The directory structure is as advised by gradle so my source is in src\main\java and test is in src\test\java.
However, because the package structure of src\test is almost exactly similar to src\main, during the test run phase in gradle, I get a bunch of
java.lang.NoClassDefFoundError
even though I can clearly see the code under ,say, src\main\A.B.C\Y\X.java. I am suspecting that while running the tests, the class to import is being searched under src\test\A.B.C\Y where, of course, the class X is not present
I've been creating my own gradle plugin for the last few days (partly for learning, and partly to clean up some gradle build scripts I have laying around), however I've run into a problem that I can't figure out how to fix. In my plugin jar there is an interface named me.alxandr.gradle.bintray.maven.MavenPackage, yet when I try to import it I get an error saying that it can't be found. This is really weird, because the plugin is obviously running (I'm seeing output from it, and it's tasks are registering).
Currently I've done a hack to get around this as following:
project.ext.MavenPackage = MavenPackage
This just makes MavenPackage an available name in the buildscript, which works, but I loose any editor support for it cause it's entirely dynamic. Is there any way I can (from my plugin) get the buildscript to import a package when it's applied? Like how MavenPublication is in scope without me needing to import it. If not, why can I not import classes from my plugin package?
The entire source code is available at https://github.com/Alxandr/gradle-utils. You can see an attempted here: https://github.com/Alxandr/gradle-utils/blob/master/gradle/publish.gradle#L1. The current code works as is (with the hack explained above), but I'm just looking for a better way to do this.
In order to use a class from your plugin in your Gradle script, you must add the plugin JAR to the buildscript classpath.
Here's how to do just that:
buildscript {
repositories { /* where to get your plugin jar from, e.g. mavenLocal() */ }
dependencies {
classpath 'some_group:me.alxandr.plugin:1.0.0'
}
}
import me.alxandr.gradle.bintray.maven.MavenPackage
You can find more information in the Gradle User Guide about using external dependencies in your build script
My groovy file contains:
#Grapes([
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.7'),
#Grab('org.apache.httpcomponents:httpmime:4.5.1')
])
.......code
I am trying to compile groovy and java code. But I am getting below error:
java.lang.RuntimeException: Transform groovy.grape.GrabAnnotationTransformation#69bda33a cannot be run
This works for me, note that I did change HttpBuilder to v.0.7.1:
#Grapes([
#Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.7.1'),
#Grab(group='org.apache.httpcomponents', module='httpmime', version='4.5.1')
])
Likely way too late for you to care, but I saw the same error just now.
I suspect the problem is that the #Grab annotation can't take effect because Maven is controlling the dependencies, or perhaps because Maven is trying to compile both Groovy and Java code, and the class loader created by the #Grab annotation can't influence the Java code.
Upshot is, I suspect you (and I) need to move the dependency out of the Groovy class in question, and put it into the pom.xml file Maven is using.
Me and my team are working on a project with a lot of modules. We are using gradle for the project and everyone is new to gradle. We have a Main parent project i.e, parent build with the details of project dependencies. We want to add the integration_test task configuration to all the modules so that we can call the command gradle integration_test. So is there any way or concept of writing the configuration in the main module and make the child projects import the same configuration.
FYI: I tried it by directly adding it to the main project but got an error saying the classpath for the files which I specified does not exists. Any help or thought would be appreciated. Thanks in advance.
Is there a particular reason to split "integration tests" from the standard test task?
If so, you can run the same script for all subprojects from the main project's build file: https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:subproject_configuration
For instance:
subprojects {
task integrationTest {
// whatever you need
}
}
I am note sure if this is what you talk about in the last paragraph. If so, please attache the error message you get.
It is also possible to "import" some configuration by subprojects, but the above definition is better in most scenarios.