Gradle-community | Community-support

Channels

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.
v
1 reply · 2 participants
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.
2 replies · 2 participants

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"
}

9 replies · 2 participants

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
v
7 replies · 2 participants
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)
v
3 replies · 2 participants
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?
1 reply · 2 participants
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.
m
3 replies · 2 participants
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?
v
5 replies · 3 participants

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

11 replies · 2 participants

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...

13 replies · 4 participants

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?

16 replies · 4 participants

Nikolay

11/29/2022, 9:08 AM

Hello, I have just attempted to upgrade gradle from

7.5.1

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
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?
d
1 reply · 2 participants
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.
v
17 replies · 3 participants
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?
c
j
27 replies · 3 participants

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.

11 replies · 3 participants

r
rrva
11/30/2022, 11:14 PM
or maybe

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... 🤔

50 replies · 3 participants

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?
v
10 replies · 3 participants

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?

10 replies · 3 participants

Jakub Chrzanowski

12/01/2022, 1:07 PM

Hi, folks! I’ve bumped the Kotlin Gradle plugin version from

1.7.10

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?

6 replies · 3 participants

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.

27 replies · 3 participants

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?
c
v
10 replies · 3 participants
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?
m
v
3 replies · 3 participants
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?
c
5 replies · 3 participants