Is it somehow possible to exclude test classes from java-to-ObjcC conversion with j2objc-gradle plugin?
The J2ObjC Gradle Plugin can exclude files from both translation and tests. It uses Ant style exclude / include pattern matching on filenames. This is is described in the Gradle documentation with examples and the PatternFilterable class.
As a simple example:
j2objcConfig {
...
testPattern {
// Only run Java unit tests that end with "Test.java"
include '**/*Test.java'
// Exclude a single test without needing to specify the full path
exclude '**/LogTest.java'
// Exclude all tests within "ignoreDirectory"
exclude 'ignoreDirectory/**'
}
...
}
Related
In the regular Javadoc generation process, we can simply exclude a class or package by adding the below lines.
exclude '**/SampleClass.java'
exclude '**/com/example/java**'
Question: How to exclude/suppress a single Kotlin/java class with the Dokka tool ??
Below is the code to exclude a package.
Is there any option to exclude a particular class?
perPackageOption {
matchingRegex.set("com.example.xxx.xxx.package.*")
suppress.set(true)
}
Dokka tool ref: https://kotlinlang.org/docs/kotlin-doc.html
Tool configurations: https://kotlin.github.io/dokka/1.5.0/user_guide/gradle/usage/#configuration-options
Coming from Maven, I'm exploring Gradle as an alternative. Technologies: Java 11, jUnit 5, Maven 3.6, Gradle 5.6.
I'm stuck in configuring the integration tests. Following the default naming conventions of Maven's Surefire and Failsafe plugins, my tests live in the standard test directory and are distinguished by their suffix: unit tests end in Test.java and integration tests end in IT.java.
Is it possible to have the same setup in Gradle? So far I've seen two ways:
use jUnit5's tags (which means I would have to go and tag every integration test)
use separate directories for unit and integration tests
Ideally, I'd like to keep my folder structure as-is, because it affects multiple git repositories.
Okay, I think I managed to get it working with source sets, thanks to the feedback of Lukas and Slaw.
Please let me know if this can be improved:
// define the dependencies of integrationTest, inherit from the unit test dependencies
configurations {
integrationTestImplementation.extendsFrom(testImplementation)
integrationTestRuntimeOnly.extendsFrom(testRuntimeOnly)
}
sourceSets {
test {
java {
// exclude integration tests from the default test source set
exclude "**/*IT.java"
}
}
// new source set for integration tests
integrationTest {
// uses the main application code
compileClasspath += sourceSets.main.output
runtimeClasspath += sourceSets.main.output
java {
// the tests are at the same directory (or directories) as the unit tests
srcDirs = sourceSets.test.java.srcDirs
// exclude the unit tests from the integration tests source set
exclude "**/*Test.java"
}
resources {
// same resources directory (or directories) with the unit tests
srcDirs = sourceSets.test.resources.srcDirs
}
}
}
// define the task for integration tests
task integrationTest(type: Test) {
description = "Runs integration tests."
group = "verification"
testClassesDirs = sourceSets.integrationTest.output.classesDirs
classpath = sourceSets.integrationTest.runtimeClasspath
shouldRunAfter test
// I'm using jUnit 5
useJUnitPlatform()
}
// make the check task depend on the integration tests
check.dependsOn integrationTest
I'm trying to start using Kotlin DSL with gradle in the project with the following restrictions:
Project has different modules (moreover: sometimes these modules use different plugins, however if two projects uses the same plugin then version of the plugins are the same).
Project has internal corporate repositories only (e.g. we don't use jcenter directly, we use proxy for it).
What we have with Groovy:
Some common configurations items are excluded to the separate scripts. Please check the example below.
Gradle modules include these files.
As a result (just based on my example):
We don't need to add the same code lines into the each module.
The most of projects have difference just with dependency list.
I tried to reproduce the same with Gralde KTS and received the following difficulties:
I'm unable to apply plugin in the include file and use it in the module. In this case I receive compilation error (because plugin types are not added into the module script).
I'm unable to extract constants to the something common to use them in the each scripts (root build.gradle.kts inclusive). With Groovy I can just use variable like springBootVersion, however with Kotlin Script I have to create the same property in the each module file.
Precompiled script plugins does not work without public repositories access (e.g. I'm unable to configure common script file with idea "just use default embedded Kotlin Script version, download all dependencies from these urls: ...".
Include file sample:
apply plugin: 'kotlin'
compileKotlin {
kotlinOptions {
jvmTarget = "1.8"
}
}
compileTestKotlin {
kotlinOptions {
jvmTarget = "1.8"
}
}
Gradle module sample:
apply from: "${rootDir}/gradle/include/kotlin-common-include.gradle"
dependencies {
compile project(':my.project.libraries.common')
compile group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: springBootVersion
}
Questions:
How can I put all common constants (such as dependency versions) to the separate file to include them just by using something like springBootVersion or Constants.springBootVersion with compile-time checks?
How can I extract plugin applying to the include scripts (to avoid Gradle module scripts overload)?
How can I use precompiled script plugins without public global repositories access?
Additional links:
Issue for Gradle KTS for plugin applying.
Issue for Gradle KTS for shared constants extracting.
There are limitations in Kotlin DSL currently (5.3) that prevents to have compile-time checks everywhere. In order for Kotlin DSL to work it has to add extensions on top of the Gradle API and it can't do it magically. First of all you need to go through Kotlin DSL Primer page to understand it.
How can I extract plugin applying to the include scripts (to avoid Gradle module scripts overload)?
The one way to do it is to use precompiled build scripts with Kotlin DSL Plugin. In order to do it you need to move your script into $rootDir/buildSrc project. Here how it might look like:
// $rootDir/buildSrc/build.gradle.kts
plugins {
`kotlin-dsl`
}
repositories {
maven {
url = uri("http://host:8082/artifactory/...")
}
}
Then put your common script like that:
// $rootDir/buildSrc/src/main/kotlin/common.gradle.kts
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
plugins {
kotlin("jvm") version "1.3.21"
}
tasks.compileKotlin {
kotlinOptions.jvmTarget = "1.8"
}
tasks.compileTestKotlin {
kotlinOptions.jvmTarget = "1.8"
}
Then you can apply this script as to a plugin like that:
// $rootDir/build.gradle.kts
subprojects {
apply(id = "common")
}
How can I use precompiled script plugins without public global repositories access?
Configuring custom repositories for pre-compiled scripts plugin is no different that your usual build script. Do it like that:
// $rootDir/buildSrc/settings.gradle.kts
pluginManagement {
repositories.maven {
url = uri("http://host:8082/artifactory/...")
}
}
The other way around that if you don't want to use precompiled plugins is to configure extensions explicitly. You can do it like that:
// $rootDir/gradle/common.gradle.kts
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
tasks.withType<KotlinCompile> {
kotlinOptions.jvmTarget = "1.8"
}
And in main script:
// $rootDir/build.gradle.kts
subprojects {
apply {
plugin(KotlinPlatformJvmPlugin::class)
from("common.gradle.kts")
}
}
How can I put all common constants (such as dependency versions) to the separate file to include them just by using something like springBootVersion or Constants.springBootVersion with compile-time checks?
There is no good way to do it currently. You can use extra properties, but it won't guarantee compile time checks. Something like that:
// $rootDir/dependencies.gradle.kts
// this will try to take configuration from existing ones
val compile by configurations
val api by configurations
dependencies {
compile("commons-io:commons-io:1.2.3")
api("some.dep")
}
// This will put your version into extra extension
extra["springBootVersion"] = "1.2.3"
And you can use it like this:
// $rootDir/build.gradle.kts
subprojects {
apply {
plugin<JavaLibraryPlugin>()
from("$rootDir/dependencies.gradle.kts")
}
And in your module:
// $rootDir/module/build.gradle.kts
// This will take existing dependency from extra
val springBootVersion: String by extra
dependencies {
compile("org.spring:boot:$springBootVersion")
}
To add a simple dependency on test source sets from an another subproject I can do:
testCompile project(':subFoo1').sourceSets.test.output
This solution works, but in many cases it is not intended to add the whole source set as a dependency. For example I would like to use only test data builders and in that case files like test-logback.xml (and regular tests) pollute my test classpath in the master module.
I tried the idea with test JAR (which can have filtered content, but is problematic as a dependency) and some combination with eachFileRecurse, but with no luck.
My question. How can I add only a subset of given source set(s) (e.g. only classes with builders matching **/*Builder.* pattern) as a testCompile dependency in another subproject?
You'll want something along the lines of:
upstream/build.gradle:
apply plugin: "java"
task testJar(type: Jar) {
classifier = "tests"
from sourceSets.test.output
exclude "**/*Test.class"
}
artifacts {
testRuntime testJar
}
downstream/build.gradle:
apply plugin: "java"
dependencies {
testCompile project(path: ":upstream", configuration: "testRuntime")
}
Instead of using testRuntime, you could also declare (e.g. configurations { testFixture }) and use a custom configuration, which would give you more control over which external dependencies are passed on to downstream projects. Yet another option would be to declare a separate source set for the part of the test code that is to be passed on. (This would also give you separate compile and runtime configurations to work with.)
PS: Reaching out into another project's object model (e.g. project(':subFoo1').sourceSets.test.output) is problematic, and should be avoided when possible.
Currently I have the following build.gradle file:
apply plugin: 'java'
sourceSets {
main {
java {
srcDir 'src/model'
}
}
}
dependencies {
compile files('libs/mnist-tools.jar', 'libs/gson-2.2.4.jar')
runtime fileTree(dir: 'libs', include: '*.jar')
}
This build.gradle file is for my repository here. All of my main files are in src/model/ and their respective tests are in test/model.
How do I add a JUnit 4 dependency correctly and then run those tests in the folders of tests/model?
How do I add a junit 4 dependency correctly?
Assuming you're resolving against a standard Maven (or equivalent) repo:
dependencies {
...
testCompile "junit:junit:4.11" // Or whatever version
}
Run those tests in the folders of tests/model?
You define your test source set the same way:
sourceSets {
...
test {
java {
srcDirs = ["test/model"] // Note #Peter's comment below
}
}
}
Then invoke the tests as:
./gradlew test
EDIT: If you are using JUnit 5 instead, there are more steps to complete, you should follow this tutorial.
If you set up your project with the default gradle package structure, i.e.:
src/main/java
src/main/resources
src/test/java
src/test/resources
then you won't need to modify sourceSets to run your tests. Gradle will figure out that your test classes and resources are in src/test. You can then run as Oliver says above. One thing to note: Be careful when setting property files and running your test classes with both gradle and you IDE. I use Eclipse, and when running JUnit from it, Eclipse chooses one classpath (the bin directory) whereas gradle chooses another (the build directory). This can lead to confusion if you edit a resource file, and don't see your change reflected at test runtime.
If you created your project with Spring Initializr, everything should be configured correctly and all you need to do is run...
./gradlew clean test --info
Use --info if you want to see test output.
Use clean if you want to re-run tests that have already passed since the last change.
Dependencies required in build.gradle for testing in Spring Boot...
dependencies {
compile('org.springframework.boot:spring-boot-starter')
testCompile('org.springframework.boot:spring-boot-starter-test')
}
For some reason the test runner doesn't tell you this, but it produces an HTML report in build/reports/tests/test/index.html.
This is for Kotlin DSL (build.gradle.kts) and using JUnit 5 (JUnit platform):
tasks.test {
// Discover and execute JUnit4-based tests
useJUnit()
// Discover and execute TestNG-based tests
useTestNG()
// Discover and execute JUnit Platform-based (JUnit 5, JUnit Jupiter) tests
// Note that JUnit 5 has the ability to execute JUnit 4 tests as well
useJUnitPlatform()
}
dependencies {
testImplementation("org.junit.jupiter:junit-jupiter:5.8.2")
// ...
}
testCompile is deprecated. Gradle 7 compatible:
dependencies {
...
testImplementation 'junit:junit:4.13'
}
and if you use the default folder structure (src/test/java/...) the test section is simply:
test {
useJUnit()
}
Finally:
gradlew clean test
Alos see: https://docs.gradle.org/current/userguide/java_testing.html
If you want to add a sourceSet for testing in addition to all the existing ones, within a module regardless of the active flavor:
sourceSets {
test {
java.srcDirs += [
'src/customDir/test/kotlin'
]
print(java.srcDirs) // Clean
}
}
Pay attention to the operator += and if you want to run integration tests change test to androidTest.
GL