Sebastian Schuberth
03/14/2023, 5:28 PMjava.lang.ClassCastException: class org.gradle.internal.logging.slf4j.OutputEventListenerBackedLogger cannot be cast to class ch.qos.logback.classic.Logger
. So, looks like Gradle is overriding the root logger of my app. Any idea how to avoid that?Adam
03/14/2023, 5:49 PMbuildSrc/build.gradle.kts
, and the plugin versions would be the same in both the convention plugins, and if they were applied directly in subprojects. I liked that there was one central place were the plugin versions were defined.
When I change from buildSrc to an included build, I lose this feature. Even though the plugins are still defined in build-logic/build.gradle.kts
I have to specify the plugin version again in subprojects. This means there's not a central place where plugins are defined.
I know there's plugin aliases in libs.versions.toml
, but I'm not a fan of this because the kts implementation is janky ("val Project.libs: LibrariesForLibs' can't be called in this context..."), and I have to define both the plugin ID and the Maven coordinates. I preferred the buildSrc method.
Is there a nice way of having all the plugins defined in one place while using included build?Eric Kolotyluk
03/14/2023, 8:38 PMdata-store-api % gradle clean test --scan
> Task :compileTestFixturesGroovy FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileTestFixturesGroovy'.
> Cannot infer Groovy class path because no Groovy Jar was found on class path: [/Users/eric.kolotyluk/git/autonomous-iam/eps/data-store-api/build/libs/data-store-api-1.0-SNAPSHOT.jar, /Users/eric.kolotyluk/git/autonomous-iam/eps/data-store-api/build/classes/java/testFixtures]
Looking at the scan I can see that while Groovy is on the compileClasspath
it is not on the testFixturesCompileClasspath
where I would have assumed compileTestFixturesGroovy
could have gotten it from the compileClasspath
Is this expected behaviour? It is new behaviour that has changed after upgrading to Java 11, Groovy 4, and the latest version of Spock.
My build.gradle
looks like
// mandatory dependencies for using Spock from <https://github.com/spockframework/spock-example/blob/master/build.gradle>
implementation platform("org.apache.groovy:groovy-bom:${apacheGroovyVersion}")
implementation "org.apache.groovy:groovy"
testImplementation platform("org.spockframework:spock-bom:${spockVersion}")
testImplementation "org.spockframework:spock-core"
Jendrik Johannes
03/15/2023, 9:01 AM// JaCoCo report for *all* Test tasks in the project
jacocoReport.executionData(project.tasks.withType(Test::class.java).map { testTask ->
// The 'map' above is the normal 'map' on collections, we loose the task dependency information
jacocoReport.dependsOn(testTask)
testTask.extensions.getByType(JacocoTaskExtension::class.java).destinationFile
})
Jendrik Johannes
03/15/2023, 10:07 AMReportingExtension
and that you could do (since 7.4):
reporting.reports.register("myownReport", JacocoCoverageReport::class.java) { report ->
report.testType.set(TestSuiteType.UNIT_TEST)
report.reportTask.configure {
// ...
}
}
This always binds the task to a specific "testType" – or a specific test suite. And with that to one test task. Is there some recommended way to setup a report for all suites (all test tasks). If I want the coverage of everything? Something planned in that direction?Markus Maier
03/15/2023, 2:08 PM-x
on the commandline anymore, else I get this (in under 1s, with only "org.gradle" in the stacktrace):
The default project is not yet available for build.
This even happens when my script plugin is empty and its build only applies the groovy-gradle-plugin
and does nothing else.
My included-build `settings.gradle`s look somewhat like this:
pluginManagement {
includeBuild '../conventions'
}
plugins {
id 'script-plugin' <<<< this causes the error, -x works fine without it
}
I have a minimal reproducer I could share, so it's not anything else that my build is doing.
This feels like a bug, when -x
breaks a setup that works fine otherwise, but I might be doing something unsupported with this setup. Do you have any hints on how I could resolve this problem? Or maybe better ways to avoid the plugin repo duplication than a settings plugin?El Zhang
03/15/2023, 2:18 PMColton Idle
03/15/2023, 3:06 PMgoogle()
repo is at
<https://dl.google.com/dl/android/maven2/>
which 404's. Should I be using a different declaration for googls mavenIvan Alvarado
03/15/2023, 4:29 PMassemble
).
The bug: Sometimes, a developer will add a new empty module to the project:
• no dependencies in the gradle script
• no source files in the module
• just adds the module with build.gradle
that specifies whether it's an android library or a kotlin library
• adds it to the settings.gradle
• updates the CODEOWNERS
file for Github
• DOES NOT attach it to the project graph, meaning it's not reachable from the :app
module
• no other project module depends on it
This seems like a trivial change. There's no source files and the module is unreachable. But, when the dev opens a PR and CI runs against these changes we start seeing failures and the failures are not always. For example, in our most recent case we experienced:
com.example.App-mergeDebugResources-149:/values/values.xml:123: error: resource drawable/ic_gradient_border (aka com.example:drawable/ic_gradient_border) not found.
for multiple resources.
In another case, we experienced Unresolved reference: GeneratedClass
for generated proto classes. What I'm trying to convey is that the error is not always the same.
What we've discovered is that if we purge (delete) the cache entries whose output was used for these files/resources from the remote cache, (in these cases the tasks that generate ic_gradient_border
resource or GeneratedClas
class file) the failure goes away! In other words, if the task that generates the class file for GeneratedClass
is :example-library:generateProto
and we see that its output was a cache-hit on the remote cache (FROM-CACHE
) (which is always the case for these errors), when we delete the cache entry from all remote cache nodes, the error goes away when we re-run the failing task.
We've also discovered that renaming the new module the dev introduced also fixes all the issues. Thus, we know this is an issue with our remote cache, we just don't have consistent reproducible steps as this only happens sometimes a dev introduces a new empty module.
Anyone else run into a similar issue or any ideas on what could be happening here?Dariusz Kuc
03/15/2023, 5:51 PMpublishPluginJar
does not depend on my custom task yet uses its output. I find it confusing as I'd assume in order to publish a JAR it would have to compile it first which already has proper dependency.... I could add the explicit dependency on the task but I'm wondering whether I am missing something else?Adam
03/15/2023, 11:41 PMExtensiblePolymorphicDomainObjectContainer
to capture various types of data from plugin users. On paper this seems like a good idea, because I can define a common interface and the implementing classes can have the correct @Input
@InputFiles
etc annotations
But when I try to use ExtensiblePolymorphicDomainObjectContainer
in a task, I find I can't re-use the values that were added to the container in my extension. I get an error: this type is not known to this container
Is it possible to re-use a ExtensiblePolymorphicDomainObjectContainer
in a sensible way? Or is there an alternative?
I found this issue, but it's not had an update https://github.com/gradle/gradle/issues/20833
Example in the thread 🧵Hantsy Bai
03/16/2023, 7:30 AMIvan CLOVIS Canet
03/16/2023, 9:30 PMprojectName/
app/
build.gradle.kts
backend/
build.gradle.kts
shared/
build.gradle.kts
build.gradle.kts
settings.gradle.kts
However, when I publish them, they are of the shape <my-group>:app:<version>
, <my-group>:backend:<version>
and <my-group>:shared:<version>
instead of <my-group>:projectName-app:<version>
, <my-group>:projectName-backend:<version>
and <my-group>:projectName-shared:<version>
, meaning my different repositories will overwrite each other's artifacts!
Yet, if we're expected to add the project name to the folders:
projectName/
projectName-app/
build.gradle.kts
projectName-backend/
build.gradle.kts
projectName-shared/
build.gradle.kts
build.gradle.kts
settings.gradle.kts
then the typesafe project accessors are generated as project.projectNameApp
which is obviously less readable, especially when the repository has multiple subprojects (project.extra.example
becomes project.extra.projectNameExtraExample
, etc).Adam
03/17/2023, 9:49 AMcheck
task these tests don’t appear nicely alongside the JUnit tests. And I would like it if the default was to continue-on-error, so a failure in one subproject doesn’t stop other checks.
Is it possible to dynamically or programatically ‘create’ a unit test via a Gradle task, without writing a @Test
? So that these checks will be picked up by any test listeners via the Test Launcher API, appear in the rest report, and ideally IntelliJ will be able to display it nicely as an error?melix
03/17/2023, 2:45 PMMarek
03/17/2023, 4:59 PMbuildSrc
in a regular groovy build.gradle file? I am trying using apply plugin: PluginName
but it fails with Could not get unknown property 'PluginName' for project ':app'
.Sebastian Schuberth
03/17/2023, 6:04 PMToolingModelBuilder
? In the model that I build all lists are empty despite me filling them in the model builder, whereas primitive string types are returned correctly to the host application.Sebastian Schuberth
03/17/2023, 9:39 PMAdam
03/18/2023, 3:08 PMYaniv Krim
03/19/2023, 2:20 PMrc
versions of dependncies?J.T. McQuigg
03/20/2023, 3:29 AMpshakhov
03/20/2023, 8:22 AMPhilip W
03/20/2023, 6:26 PMMatt Groth
03/20/2023, 7:26 PMZak Taccardi
03/20/2023, 7:54 PMString
name instead of a Class<T>
?Igor Wojda
03/21/2023, 6:18 PMorg.gradle.jvm-test-suite
plugin reference in versions catalog? (to avoid strings in plugin
block)Sebastian Schuberth
03/22/2023, 8:07 AMresolvedVariant.attributes.getAttribute(Category.CATEGORY_ATTRIBUTE)
in a Gradle plugin written in Kotlin returns null
whereas using resolvedVariant.attributes.getAttribute(Attribute.of("org.gradle.category", String::class.java))
succeeds. Is it expected that the category attribute seems to lose its dedicated type and "coerces" to String?Matthew Inger
03/22/2023, 3:53 PMgradle.settingsEvaluated
block as well. I would think the getByName
would fail if that handn’t been applied yet. However, I don’t see the actual version getting changed when doing it this way.
gradle.settingsEvaluated {
dependencyResolutionManagement {
versionCatalogs {
getByName("internalLibs") {
library("alias", "group:artifact:version"")
}
}
}
}
Sergei Ponomarev
03/22/2023, 8:21 PMsit(JvmTestSuite) {
...
targets {
configureEach {
testTask.configure {
jvmArgs += "-Dparam=value"
}
}
}
The line jvmArgs += "-Dparam=value"
is executed every run during configuration phase even when running clean
task. Is it possible to perform this configuration only when the task is actually needed?Eugen Mayer
03/23/2023, 8:37 AMEugen Mayer
03/23/2023, 8:37 AM