community-support
  • t

    thadhouse

    11/26/2022, 12:34 AM
    Looks like bintrays certificate expired. So jcenter and therefore the plug-in portal are down again.
  • t

    thadhouse

    11/26/2022, 5:36 AM
    Semi related to the plugin portal, is there a way to have the same repository settings between buildSrc and settings.gradle automatically. We figured out thats why our workarounds never worked, because buildSrc always put the plugin portal first, but we were only changing settings.gradle.
  • p

    Philip W

    11/26/2022, 12:02 PM
    Is it possible to check the
    repositoriesMode
    from a project plugin? I enabled
    dependencyResolutionManagement {
        repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    }
    but one plugin adds other repositories, so my idea is to disable adding repos in the plugin if this mode is enabled. But I don't see an API to check this mode.
  • e

    Eric Kolotyluk

    11/26/2022, 4:41 PM
    Gradle
    run
    task issues I am playing with a Java Loom project, but I have been trying to configure the
    run
    task to run my code...
    eric.kolotyluk@Y2RCV7009N loom-laboratory % ./gradlew run
    
    > Task :run FAILED
    Hello world!
    Exception in thread "main" java.lang.NoClassDefFoundError: jdk/incubator/concurrent/StructuredTaskScope$ShutdownOnFailure
            at com.forgerock.poc.loom.Application.main(Application.java:49)
    Caused by: java.lang.ClassNotFoundException: jdk.incubator.concurrent.StructuredTaskScope$ShutdownOnFailure
            at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
            at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
            at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
            ... 1 more
    
    FAILURE: Build failed with an exception.
    
    * What went wrong:
    Execution failed for task ':run'.
    > Process 'command '/Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
    
    * 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 503ms
    2 actionable tasks: 1 executed, 1 up-to-date
    application {
        mainClass.set("com.forgerock.poc.loom.Application")
        applicationDefaultJvmArgs += "--enable-preview"
        // applicationDefaultJvmArgs += "--add-modules jdk.incubator.concurrent"
    }
  • Mehdi Janbarari

    Mehdi Janbarari

    11/27/2022, 6:52 AM
    Hey Folks! I have a bug with configuration-cache in Gradle. once I change a property inside
    gradle.properties
    the configuration cache still reusing and provides the old property value but my plugin needs the updated value! I need your help 🙂 #configuration-cache
  • t

    thadhouse

    11/27/2022, 7:12 AM
    On a semi related note, does changing command line -P properties invalidate the cache? If not, is there some other type of property that can change things during configuration time (which rules out task command line inputs)
  • c

    Christoph Loy

    11/28/2022, 5:57 AM
    Hey guys 🙂 Just out of interest: Is there any reason why the Gradle Repo itself uses a build-logic directory instead of good old buildSrc for its own build? 🙂 Any advantages of that?
  • t

    Thomas Keller

    11/28/2022, 9:24 AM
    After upgrading to Gradle 7.6 a plugin we’re using breaks. Apparently JVM projects no longer have a
    @pom
    artifact available, so the plugin fails: https://github.com/jaredsburrows/gradle-license-plugin/blob/master/gradle-license-[…]/src/main/kotlin/com/jaredsburrows/license/LicenseReportTask.kt Is there any alternative to this configuration? The rationale of the plugin is to query all dependencies and generate a license report off of them.
  • p

    Philip W

    11/28/2022, 11:06 AM
    I know adding repositories inside a plugin isn't a good idea, but when using
    dependencyResolutionManagement
    in settings and
    project.repositories.maven { ... }
    in your plugin, the previously declared repositories are overwritten by the plugin, not added. Is this somehow expected or a bug?
  • a

    Arimil

    11/28/2022, 3:46 PM
    Are platforms not transitive? If I have myplatform:
    dependencies {
        constraints {
            api(platform("org.springframework.boot:spring-boot-dependencies:2.7.5"))
        }
    }
    And then in another project I specify:
    dependencies {
        implementation(enforcePlatform("com.example:myplatform:1.0.0"))
        implementation("ch.qos.logback:logback-core")
    }
    This will fail to find the version for
    logback-core
    that is specified inside
    spring-boot-dependencies
    .
  • m

    Malte Schirmacher

    11/28/2022, 4:32 PM
    Hi! given this dependeny tree:
    +--- com.graphhopper:graphhopper-core:6.2
    |    +--- com.graphhopper:graphhopper-web-api:6.2
    |    |    +--- com.fasterxml.jackson.core:jackson-core:2.10.5 -> 2.13.3
    |    |    +--- com.fasterxml.jackson.core:jackson-databind:2.10.5.1 -> 2.13.3 (*)
    |    |    +--- com.graphhopper.external:jackson-datatype-jts:0.12-2.5-1
    |    |    |    +--- com.fasterxml.jackson.core:jackson-databind:2.9.6 -> 2.13.3 (*)
    |    |    |    \--- org.locationtech.jts:jts-core:1.15.1
    |    |    \--- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.10.5 -> 2.13.3
    |    |         +--- com.fasterxml.jackson.core:jackson-core:2.13.3
    |    |         +--- com.fasterxml.jackson.core:jackson-annotations:2.13.3
    |    |         +--- com.fasterxml.jackson.core:jackson-databind:2.13.3 (*)
    |    |         +--- org.codehaus.woodstox:stax2-api:4.2.1
    |    |         +--- com.fasterxml.woodstox:woodstox-core:6.2.7 -> 6.4.0 (*)
    |    |         \--- com.fasterxml.jackson:jackson-bom:2.13.3 (*)
    |    +--- com.carrotsearch:hppc:0.8.1
    |    +--- org.codehaus.janino:janino:3.1.2 -> 3.1.7
    |    |    \--- org.codehaus.janino:commons-compiler:3.1.7
    Am i right if i think that
    com.graphhopper:graphhopper-core:6.2
    ACTUALLY dependes in version 3.1.2 of
    janino
    but in fact gradle chooses to provide version 3.1.7? How do i find out WHY gradle does that? there is no other library declaring a dependency on janino...
  • Sid B

    Sid B

    11/28/2022, 7:15 PM
    I have 3 artifactory repositories defined like this
    repositories {
        maven {
            url = uri("<https://myorg.org/artifactory/external>")
            credentials {
                username = providers.gradleProperty("artifactoryUsername").get()
                password = providers.gradleProperty("artifactoryPassword").get()
            }
        }
        maven {
            url = uri("<https://myorg.org/artifactory/internal>")
            credentials {
                username = providers.gradleProperty("artifactoryUsername").get()
                password = providers.gradleProperty("artifactoryPassword").get()
            }
        }
        maven {
            url = uri("<https://myorg.org/artifactory/legacy>")
            credentials {
                username = providers.gradleProperty("artifactoryUsername").get()
                password = providers.gradleProperty("artifactoryPassword").get()
            }
        }
    }
    I want to use Safe Credentials here, but then I have to define three sets of duplicate usernames and passwords. Is there a workaround?
  • Nikolay

    Nikolay

    11/29/2022, 9:08 AM
    Hello, I have just attempted to upgrade gradle from
    7.5.1
    to
    7.6
    and I get the following error:
    A problem occurred configuring project ':buildSrc'.
    > Could not resolve all files for configuration ':buildSrc:classpath'.
       > Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20.
         Required by:
             project :buildSrc > org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.7.20 > org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.20
          > Multiple incompatible variants of org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 were selected:
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 variant gradle70RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.0, org.gradle.status=release, org.gradle.usage=java-runtime}
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 variant gradle71RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.1, org.gradle.status=release, org.gradle.usage=java-runtime}
    
       > Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20.
         Required by:
             project :buildSrc > org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.7.20 > org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.20
             project :buildSrc > org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.7.20 > org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.20 > org.jetbrains.kotlin:kotlin-gradle-plugin-model:1.7.20
          > Multiple incompatible variants of org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 were selected:
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 variant gradle70RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.0, org.gradle.status=release, org.gradle.usage=java-runtime}
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 variant gradle71RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.1, org.gradle.status=release, org.gradle.usage=java-runtime}
    
       > Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.10.
         Required by:
             project :buildSrc > org.gradle.kotlin.kotlin-dsl:org.gradle.kotlin.kotlin-dsl.gradle.plugin:2.4.1 > org.gradle.kotlin:gradle-kotlin-dsl-plugins:2.4.1 > org.jetbrains.kotlin:kotlin-sam-with-receiver:1.7.10
          > Multiple incompatible variants of org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 were selected:
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 variant gradle70RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.0, org.gradle.status=release, org.gradle.usage=java-runtime}
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.20 variant gradle71RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.1, org.gradle.status=release, org.gradle.usage=java-runtime}
    Not sure what is the problem. Any help would be appreciated.
  • v

    Vampire

    11/29/2022, 9:33 AM
    tapchicoma [10:49 Uhr] Those who see variant selection issue on using KotlinGradlePlugin +
    kotlin-dsl
    plugins after updating to Gradle 7.6 should also add
    id("org.jetbrains.kotlin.plugin.sam.with.receiver") version "<kotlin_version>"
    into
    plugins { .. }
    block. Related issue that should be fixed in Kotlin 1.8.20 release.
  • nate

    nate

    11/29/2022, 1:19 PM
    Hi community members! I'm trying to gather more information about the general gradle docs experience. If you have a couple of minutes to fill out a survey on the documentation, I would very much appreciate your thoughts: https://docs.google.com/forms/d/e/1FAIpQLSclpOsiTaXqijUP17yio8-I7bCSyw7nNTCbcGcH1E59AdfsZg/viewform?usp=pp_url I'm particularly interested in your experience if you're relatively new to Gradle (less than 1 year of experience). But all feedback is welcome!
  • p

    Peter

    11/29/2022, 11:01 PM
    Hey. I've recently watched a talk about how to flatten module graphs. One of the techniques, that was mentioned, was to make some sort of API of the module (interface like module), and then have another module, implementing it. If you look at the image, there is a
    :core-api
    (interface) and
    :core
    (implementation). I'm confused how to implement that from gradle perspective. Can anyone point me in the right direction, give me any example projects, or similar?
  • Robert Elliot

    Robert Elliot

    11/30/2022, 9:12 AM
    Is it possible to run the tests with different env vars when passing the
    --tests
    argument? Context - an integration test with a timeout on the test client. When running all the tests I want the timeout to be short, when running specific tests I want it to be long so I can debug inside the server while the test is waiting for a response.
  • SomeCat

    SomeCat

    11/30/2022, 6:35 PM
    Hello folks. We have a large gradle setup, with various of proprietary (such as some sub projects not following the maven convention for src/main…). Now we want to add Kotlin as supported language. I started by adding
    id("org.jetbrains.kotlin.jvm") version ("1.6.21")
    to one of the “root” plugins sections. With that, all existing things get build … but: although I added a src/main/kotlin directory to one of the subprojects (that one follows the maven structure, so it already has src/main/java) the .kt file I placed in there doesn’t get compiled. Obviously, I don’t expect that anybody can tell me how to fix this … instead I am looking for hints/ideas how to debug this. I tried
    gradlew classes --info
    … but the few lines containing “kotlin” don’t tell anything. Using
    --debug
    isn’t much different, just more noise. So, any guidance how to approach such a problem?
  • e

    Eivind Naess

    11/30/2022, 7:11 PM
    I am sure I am going about this wrong, but is there a way I can sort-n-sift through dependencies and pick artifacts from various projects without regards for what type they are? Consider the following code:
    // Bucket to hold all dependencies
    configurations.create("implementation") {                                                                                                                                                                       
        canBeConsumed = false                                                                                                                                                                                       
        canBeResolved = false                                                                                                                                                                                       
    }                                                                                                                                                                                                               
    
    def f = configurations.create("java-configurations") {                                                                                                                                                                 
        canBeConsumed = false                                                                                                                                                                                       
        canBeResolved = true
        extendsFrom = [ configurations.implementation ]                                                                                                                                                             
    }                                                                                                                                                                                                               
    
    def ff = f.incoming.artifactView {                                                                                                                                                                              
        attributes {
            attribute(Category.CATEGORY_ATTRIBUTE, objects.named(Category, Category.LIBRARY))                                                                                                                       
            attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage, Usage.JAVA_RUNTIME))
            attribute(Bundling.BUNDLING_ATTRIBUTE, objects.named(Bundling, Bundling.EXTERNAL))
            attribute(TargetJvmVersion.TARGET_JVM_VERSION_ATTRIBUTE, JavaVersion.current().majorVersion.toInteger())                                                                                                
        }                                                                                                                                                                                                           
    }                                                                                                                                                                                                               
    
    dependencies {
        implementation project(":java-project-1")
        implementation project(":native-project-1")                                                                                                                                                                 
    }                                                                                                                                                                                                               
    
    // Dummy to test the result of the dependencies / artifactView results
    project.afterEvaluate {
        println ff.files.size() 
        println ff.files.each { fi ->                                                                                                                                                                               
            println "$fi"                                                                                                                                                                                           
        }                                                                                                                                                                                                           
    }
    The idea being to for example organize the output in a slightly different output directory than build, e.g. stage to publish a .tar.gz of all build artifacts in a particular directory structure so they don't co-reside with other artifacts like .class or .o files. Or even separate out all the test results into a specific output structure. Here, the "f" configuration, or another configuration for only native targets; cause the dependency resolution to fail in either case. Configuration "f" fails when it hits projects that doesn't have java exported variants, and a "native-link" configuration fails when it sees a Java project without any native configurations in it. In a way, I wish it could ignore dependent projects that doesn't match the configuration rather than "fail" outright. Also, the "java-configuration" doesn't specify the attributes it matches, the incoming artifactView configuration does. I was kind of hoping that not attaching attributes to a configuration, but rather use them in the artifact resolution step; it would allow me to ignore dependencies I didn't care about. I am sure this is sort of an anti-pattern to Gradle and how it was designed. I am leaning towards building a plugin that when applied to Java projects would assemble an archive that could be exported as a separate configuration with separate attributes and have them match. Similarly, but with a behavior adjusted for native projects. In the consumer project I would use "implementation" as the contextual "give me projects that list these attributes that I care about (not java, not native), but maybe "stage"?. That way, I can add dependencies that all share a common attribute that can be resolved. Just trying to wrap my head around the notion of "implementation" and the fact it feels like it means something special (almost like it is reserved) dependent on the context of the project.
  • r

    rrva

    11/30/2022, 11:14 PM
    or maybe
  • e

    Eric Kolotyluk

    11/30/2022, 11:58 PM
    eric.kolotyluk@Y2RCV7009N utils % ./gradlew clean test 
    
    FAILURE: Build failed with an exception.
    
    * Where:
    Build file '/Users/eric.kolotyluk/git/autonomous-iam/utils/build.gradle'
    
    * What went wrong:
    Could not compile build file '/Users/eric.kolotyluk/git/autonomous-iam/utils/build.gradle'.
    > startup failed:
      General error during conversion: Unsupported class file major version 63
      
      java.lang.IllegalArgumentException: Unsupported class file major version 63
            at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:199)
            at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:180)
            at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:166)
            at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:287)
    . . .
    So everything was working fine until I added to my
    build.gradle
    file
    environment 'PROCESS_LIB_INSTRUMENTATION','true'
        environment 'PROCESS_LIB_BUNDLE_LOG_LEVEL','info'
    as in
    test {
    //    useJUnit()
        useJUnitPlatform()
        maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
        environment 'PROCESS_LIB_INSTRUMENTATION','true'
        environment 'PROCESS_LIB_BUNDLE_LOG_LEVEL','info'
    }
    I see no correspondence between the change to my
    build.gradle
    and the diagnostics provided... 🤔
  • m

    melix

    12/01/2022, 10:04 AM
    The Micronaut project consists of a lot of repositories and would benefit from composite builds a lot. However, today, this doesn't quite work because of the way project identity works. For example this morning I wrote this ugly code for a coworker:
    includeBuild("../micronaut-core") {
        def modules = file("../micronaut-core/settings.gradle").readLines().findAll {
           it.startsWith('include "') && !it.startsWith('include ":test')
        }.collect { it.substring(9) - '"' }
        
        
        dependencySubstitution {
            modules.each { mod ->
                substitute module("io.micronaut:micronaut-${mod}") using project(":$mod")
            }
        }
    }
    You can see that the problem is that we have convention plugins which rename the artifact id based on the project name, so a project named
    foo
    will end up with an artifact id
    micronaut-foo
    . Is there a smarter way to avoid having to add such configuration?
  • e

    Eleanor Joslin

    12/01/2022, 11:39 AM
    Hello everyone. I'm working on a Gradle plugin that depends on classes in the
    com.github.johnrengelman.shadow
    plugin. I'm trying to upgrade it, but finding the last few releases of the plugin are missing from the Gradle Plugin Portal. I'm using Gradle 7.4.1:
    repositories {
      maven {
        url = uri("<https://plugins.gradle.org/m2/>")
      }
    }
    
    dependencies {
      api("com.github.jengelman.gradle.plugins:shadow:7.1.2")
    }
    and getting this output:
    > Task :compileKotlin FAILED
    
    FAILURE: Build failed with an exception.
    
    * What went wrong:
    Execution failed for task ':compileKotlin'.
    > Error while evaluating property 'filteredArgumentsMap' of task ':compileKotlin'
       > Could not resolve all files for configuration ':compileClasspath'.
          > Could not find com.github.jengelman.gradle.plugins:shadow:7.1.2.
            Searched in the following locations:
              - file:/Users/ejj/.m2/repository/com/github/jengelman/gradle/plugins/shadow/7.1.2/shadow-7.1.2.pom
              - <https://plugins.gradle.org/m2/com/github/jengelman/gradle/plugins/shadow/7.1.2/shadow-7.1.2.pom>
            Required by:
                project :
    I haven't committed a typo; 7.1.2 is listed as the latest version on https://plugins.gradle.org/plugin/com.github.johnrengelman.shadow but versions above 6.1.0 are missing from https://plugins.gradle.org/m2/com/github/jengelman/gradle/plugins/shadow/. If I change my dependency version to 6.1.0, it finds the module OK. What would cause it to be missing? Is there something wrong with the portal? Can I find the latest release somewhere else?
  • j

    Jakub Chrzanowski

    12/01/2022, 1:07 PM
    Hi, folks! I’ve bumped the Kotlin Gradle plugin version from
    1.7.10
    to
    1.7.22
    and got the following exception:
    A problem occurred configuring root project 'gradle-intellij-plugin'.
    > Could not resolve all files for configuration ':classpath'.
       > Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.22.
         Required by:
             project : > org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.7.22 > org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.22
          > Multiple incompatible variants of org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.22 were selected:
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.22 variant gradle70RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.0, org.gradle.status=release, org.gradle.usage=java-runtime}
               - Variant org.jetbrains.kotlin:kotlin-gradle-plugin-api:1.7.22 variant gradle71RuntimeElements has attributes {org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.jvm.environment=standard-jvm, org.gradle.jvm.version=8, org.gradle.libraryelements=jar, org.gradle.plugin.api-version=7.1, org.gradle.status=release, org.gradle.usage=java-runtime}
    
    * 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.
    Any idea what’s going one here?
  • e

    Eric Kolotyluk

    12/01/2022, 11:38 PM
    eric.kolotyluk@Y2RCV7009N helidon-nima % ../gradlew clean run
    
    > Task :helidon-nima:compileJava FAILED
    warning: using incubating module(s): jdk.incubator.concurrent
    /Users/eric.kolotyluk/git/autonomous-iam/poc/loom-laboratory/helidon-nima/src/main/java/nima/BlockingService.java:69: error: newVirtualThreadPerTaskExecutor() is a preview API and is disabled by default.
            try (var exec = Executors.newVirtualThreadPerTaskExecutor()) {
                                     ^
      (use --enable-preview to enable preview APIs)
    Note: /Users/eric.kolotyluk/git/autonomous-iam/poc/loom-laboratory/helidon-nima/src/main/java/nima/NimaMain.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    1 error
    1 warning
    
    FAILURE: Build failed with an exception.
    
    * What went wrong:
    Execution failed for task ':helidon-nima:compileJava'.
    > Compilation failed; see the compiler error output for details.
    I cannot figure out how to tell Gradle to use the javac option
    --enable-preview
    In the parent project, I don't need to; it just works. In the subproject, I tried
    tasks {
        compileJava {
            options.allCompilerArgs += "--enable-preview"
        }
    }
    but that produces
    eric.kolotyluk@Y2RCV7009N helidon-nima % ../gradlew clean run
    
    FAILURE: Build failed with an exception.
    
    * What went wrong:
    Could not determine the dependencies of task ':helidon-nima:run'.
    > Could not resolve all dependencies for configuration ':helidon-nima:runtimeClasspath'.
       > Could not create task ':helidon-nima:compileJava'.
          > java.lang.UnsupportedOperationException (no error message)
    It seems like Gradle is inconsistent between root project and subprojects.
  • Sebastian Schuberth

    Sebastian Schuberth

    12/02/2022, 12:02 PM
    Is it possible to create a precompiled init script written in Kotlin DSL, and then apply that (binary) plugin (locally) to a Gradle project whose Gradle version (as defined by the wrapper) does not support Kotlin DSL yet, but only Groovy DSL?
  • Jacob Rakidzich

    Jacob Rakidzich

    12/02/2022, 5:16 PM
    Hey, I'm looking into source dependencies. I see docs that say it's only for c++ but I also see some people using kotlin as a source dependency but I can't get it to work. Can we make a Kotlin source dependency? If so, how? Is anyone able point me in the right direction?
  • e

    Eric Kolotyluk

    12/02/2022, 11:36 PM
    In older Gradle projects I have used
    allprojects {
       . . .
    }
    and
    subprojects {
        . . .
    }
    But it's not clear those are supported in newer versions such as Gradle 7.6 and 8.0 Am I imagining things? Is this practice still usual, or are there new ways of doing it?