This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Is the plugin portal having issues?

I'm developing a catalog and a platform within the same project.

catalog

is a simple module, while

platform

is a build, which imports

catalog/build/version-catalog/libs.versions.toml

Everything works fine, except I have an egg-chicken problem: when I start from scratch (ie: clone), I have to disable first

platform

so that

catalog:generateCatalogAsToml

can have the chance to first generate the toml file which then

platform

can consume, after I enable it again Is there a solution which wouldn't involve splitting

catalog

and

platform

?

why this works fine (in a precompiled Groovy script plugin)?

tasks.withType(Jar).configureEach {
    manifest {
        attributes["Main-Class"] = mainClassName
    }
}

While on the binary Kotlin plugin counterpart, I have to resort to

doFirst/Last

, which makes sense

project.tasks.withType<Jar>().configureEach {
    doFirst {
        manifest {
            project.application {
                attributes["Main-Class"] = mainClass.get()
            }
        }
    }
}

Hi, I'm facing a weird issue again with a

StackOverflowException

caused by file collections that I don't fully understand. Basically, I have a project extension that configures an implementation of

SourceTask

. My initial approach was using a

ConfigurableFileCollection

in the extension and passing it to the task via

SourceTask#source(Object...)

. However, when I try to add sources to the collection (via ``ConfigurableFileCollection#from(Object...)``; e.g.

from("./test.txt")

) I get a SOE but only if the file exists. Am I missing something obvious here? (A few more details in 🧵)

Question for you all. Suppose I have a task laid out like this:

abstract class AbstractDatabaseTask : DefaultTask() {
  @get:Classpath
  abstract val driverClasspath: ConfigurableFileCollection
  
  @get:Input
  abstract val driverClassName: Property<String>
  
  // Derived from driverClasspath
  private val driverClassLoader: Provider<URLClassLoader> = ...
  
  // Derived from driverClasspath and driverClassName
  private val driverClass: Provider<Class<out Driver>> = ...

  // Invoke DriverManager.registerDriver() here with a driver created from driverClass
  private fun loadDriver(): Driver { ... }
  
  protected fun <T> runWithDriver(fn: () -> T): T {
    val driver = loadDriver()
    try {
      return fn()
    } finally {
      DriverManager.deregisterDriver(driver)
    }
  }
}

The intent here is that you would eventually be able to operate with JDBC in this task. I'm wondering if this is a good use case for, say, a

BuildService

that could centralize some of this logic, or if there are complications that would necessitate every task to have its own driver classloader.

Using

NotationParser

to parse to AType, I want to support say; • MyType • String • Provider<> of above • ProviderConvertible<> of above Is it possible to use the NotationConverter I registered for String while implementing the for example the Provider<> converter? So far it seems one would need to duplicate the logic inside of Provider & ProviderConvertible converters?

Is it safe for Gradle plugins to use kotlinx.coroutines as a dependency? Is there a significantly higher risk of classpath pollution or clashes?

It's late and I am trying to get my around this one. I want to to populate a property in an extension from the output of a task that is from another applied plugin, so roughly this

// Pseudo code
class MyExtension {
  Property<Content> someContent // Content can any type one wishes
}

class TaskFromOtherPlugin {
  @OutputFile
  Provider<File> getOutputFile() { ... }
}

projext.extensions.getByType(MyExtension).someContent.set(
  project.tasks.named('otherTask',TaskFromOtherPlugin).flatMap { 
     final file = it.outputFile
     // process file and return and instance of Content
  }
)

If for some reason,

someContent

is evaluated in configuration phase it will proably fail, which is the correct behaviour. However, during execution phase, it should invoke the task when the Property is evaluated. I am not actually sure, it will invoke the task at the correct time. Any suggestions?

A conversation about terraform / opentofu usage patterns with Gradle, led me to thinking about running tasks in parallel. Some background first for those not familiar with these infra management tools. Normally there is a directory with tf source code on which one runs the tool with various commands. There is also the concept of workspaces, which basically are meant to to have the same tf sourcer applies to various environments i.e. staging, production etc. Some a workspace is effectively what also is called an infra environment. With the Gradle plugin suite for terraform & opentofu, we can handle workspaces, but we also have the concept of source sets. The latter are different source sets. Each source set can have workspaces. Wit a source set you can split up your infra mgmt into for instance slow changing infra, which can be run manually , and frequent changes that you want to run in a pipeline. For each source set there is a a group of tasks created which mirror the tf commands i.e.

tfPlan

,

tfApply

etc. (for the default source set) and if you have source set called

foo

then

tfFooPlan

,

tfFooApply

. If you have additional workspaces within a sourceset i.e.

staging

and

prod

then you also have tasks like

tfPlanStaging

,

tfApplyStaging

,

tfApplyProd

,

tfPlanProd

etc. (there is a pattern here). The real question now is, how to run these in parallel? There are limitations: • we cannot run any tasks within the same source set in parallel and not even if they are from different workspaces (this is a limitation on how the tool works) • if one source set is somehow dependent on another source set, then we cannot run the tasks of those source sets in parallel (they should be in a mustRunAfter relationship). But let's just assume that will define a way that the source set relationship can be explicitly stated. These are external tools, thus invoked via

ExecSpec

and there are no classpaths involved. It does not really make sense to use workers, because they are more suited towards JVM processes. Is there a way in Gradle, to define that tasks can be run in parallel, but certain groups of tasks cannot run in parallel with other tasks in the same grouping? IOW the two groupings can run in parallel.

I have a shadowed Gradle plugin. When I publish my Gradle Plugin to maven local and consume it from another Gradle project I get the shadowed version as expected. However, if I consume the Gradle plugin in another project using a

includeBuild(...)

I get the non-shadowed version. My setup is quite minimal. I have configured the shadowJar task to have

archiveClassifier = ''

Anything else i should reconfigure here to get this working with included builds?