From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

from the Gradle code: when the buildFinished event is emitted all the registered build services are ‘stopped’, which consists of calling `.close()` for those that are `AutoCloseable`.  The listeners are added at registration time, and presumably are called in that order.
```    private &lt;T extends BuildService&lt;P&gt;, P extends BuildServiceParameters&gt; BuildServiceProvider&lt;T, P&gt; doRegister(
        String name,
        Class&lt;T&gt; implementationType,
        @Nullable P parameters,
        Integer maxParallelUsages,
        NamedDomainObjectSet&lt;BuildServiceRegistration&lt;?, ?&gt;&gt; registrations
    ) {
        BuildServiceProvider&lt;T, P&gt; provider = new BuildServiceProvider&lt;&gt;(
            buildIdentifier,
            name,
            implementationType,
            parameters,
            isolationScheme,
            instantiatorFactory.injectScheme(),
            isolatableFactory,
            services,
            listener
        );

        DefaultServiceRegistration&lt;T, P&gt; registration = uncheckedNonnullCast(specInstantiator.newInstance(DefaultServiceRegistration.class, name, parameters, provider));
        registration.getMaxParallelUsages().set(maxParallelUsages);
        registrations.add(registration);

        // TODO - should stop the service after last usage (ie after the last task that uses it) instead of at the end of the build
        // TODO - should reuse service across build invocations, until the parameters change (which contradicts the previous item)
        listenerManager.addListener(new ServiceCleanupListener(provider));
        return provider;
    }```

listeners are indeed called in the order added:
```for (ListenerDetails listener : allListeners.values()) {
                    broadcaster.maybeAdd(listener);
                }```

Thank you! This is very helpful.  I’m not sure we want to rely on this implementation detail, but we’ll think about it.

agreed, it is odd to rely on registration order - seems like the correct cleanup would follow the dependency graph.  You could simulate that by using `Closeable` (instead of AutoCloseable), to avoid the flaky ordering, and then have a build service that listens for the buildFinished event and calls close on the service in the right order.

(or just have your own interface ‘ServiceCleanup’ with a shutdown() method)

Thanks.  Your idea seems like it could work, but it would mean doing significant build activity after buildFinished for us.  We’d like to avoid that, I think we are just going to try to avoid having build services depend on close() ordering.

sounds good.  seems like you’d be doing that same work, just in a controlled order, as `close()` today is triggered on the buildFinished event.

This is unfortunately a known issue: <https://github.com/gradle/gradle/issues/12388> (with a workaround, fortunately!)

(see also <https://github.com/gradle/gradle/issues/22271> for your use case)

Thank you, Thomas – you saved my time with that. :slightly_smiling_face:
I’ll go with:
```distributionFile.convention(
    signPluginTaskProvider
        .flatMap { signPluginTask -&gt;
            when (signPluginTask.didWork) {
                true -&gt; signPluginTask.outputArchiveFile
                else -&gt; project.provider { fallbackValue }
            }
        }
)```


GradlePublish.kt.cpp

build.gradle.kts.kt

For reference here's my `build.gradle.kts` I can use this to publish to maven local and via setting the project name to be `rootProject.name = "gitlab-publish.gradle.plugin"`  this puts everything in what appears to be the right directory when published to maven local. But when I try to use the plugin `id("gitlab-publish") version "1.0-SNAPSHOT"`  it says it can't be found.
```Build file '/home/arimil/Development/gitlab-publish/build.gradle.kts' line: 6

Plugin [id: 'gitlab-publish', version: '1.0-SNAPSHOT'] was not found in any of the following sources:

* Try:
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.```


~why are you trying to apply `gitlab-publish` if the documentation specifies `plugin-publish`?~
nevermind, completely misunderstood the question...

you have to specify mavenLocal for plugin resolution as well. You can add that in your settings.gradle file inside `pluginManagement`

<https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:plugin-vs-build-repos>

I think you should open a ticket at <https://github.com/gradle/plugin-portal-requests>

take it out of the buildscript and put it in a plugin that is built with overriding `kotlinDslPluginOptions.jvmTarget.set(...)`

Huh? Java NIO exists since Java 1.4. How can you not be able to use it? *confused*

:woman-shrugging: really dunno, something's not compiling

Do you maybe try to use a fully-qualified name while also having the Java plugin applied?
Because that is what is not working, as `java` will be interpreted as the extension, not the package and then the `nio` is searched as property of the java extension which of course does not exist.
If you use an import instead, it works fine. I even tried with the `java.nio.file` which was added in Java 1.7.

Otherwise, please specify the "something"

there have been additions to nio in later jdks (such as <https://bugs.openjdk.org/browse/JDK-8219793|https://bugs.openjdk.org/browse/JDK-8219793>) but fewer than I remember. you're right, _most_ of it is already present by java 8

You need too add all "peer" dependencies to the pluginClasspath to have them in the _right_ class loader. Something like:
```val additionalPluginClasspath by configurations.creating

dependencies {
    additionalPluginClasspath("com.google.cloud.tools.jib:com.google.cloud.tools.jib.gradle.plugin:3.3.0")
}

tasks {
    pluginUnderTestMetadata {
        this.pluginClasspath.from(additionalPluginClasspath)
    }
}```
and then use it without version from your test project:
```plugins {
    id("com.google.cloud.tools.jib")
}```


umm ok, I forgot to mention that I'm declaring Jib as an `implementation` dependency of my plugin, assuming it'll get applied automatically and also loaded at test time. Does that count or am I taking the wrong assumption and doing it wrong? The official docs didn't help much in this regard

Oh, if declared as `implementation` then `additionalPluginClasspath` shouldn't be needed.

also, as I said I didn't experience any error running the exact same build from the CLI using an actual Gradle daemon

Your `ifPresent` implementation is wrong. It should `getOrNull()`, check if not null, then call the block with the value previously retrieved via `getOrNull()`. The current implementation will break if the provider returns a value on first get and null on subsequent get or something along those line. Although pretty rare, ignoring this potential behaviour is leaking abstraction as you would be assuming how the provider is calculated which is wrong.

don’t believe that to be the case.  it’s simply using the `isPresent` capabilities of the provider, without having to resolve the provider to check for presence.

`isPresent` calculate the value to determine if there is a value. It’s a hidden problem that I discussed in length with the Gradle team but no conclusion yet. The problem is there is no way to know there is a value unless the value is calculated. Part of the problem is that `null` is assumed to be no-value.

uuuuuggggghhhhhh.  thanks for flagging that.

It’s a gross approximation but given:
```def i = 0
def p = provider {
    try {
      if (i == 0) {
        return 'first'
      } else if (i == 1) {
        return null
      } else {
        return 'other'
      }
    } finally {
      i++
    }
}

if (p.present) {
    println(p.getOrNull())
}
println p.getOrNull()```
The result would be:
```&gt; Configure project :
null
other```
I use `getOrNull()` inside the condition because it would crash with no-value.

Granted, no-one should write a provider like that but if for example the provider would request something from the network and an exception occurs, it may result in that behaviour.

Maybe `zip` two, then `zip` the result with the third and the result with the fourth?
The resuld of the first two `zip`s could be a pair and triple, or POJO for example.

The trickiest part here were nested ifs, but I’ve managed it. :slightly_smiling_face:
```untilBuild.convention(
    extension.sameSinceUntilBuild
        .flatMap { sameSinceUntilBuild -&gt;
            untilBuild.map { "$it.*" }
                .takeIf { sameSinceUntilBuild }
                ?: buildNumberProvider.map { "${IdeVersion.createIdeVersion(it).baselineVersion}.*" }
        }
        .zip(extension.updateSinceUntilBuild) { untilBuild, updateSinceUntilBuild -&gt;
            untilBuild.takeIf { updateSinceUntilBuild }
        }
)```

I’ve used <https://github.com/wernerdegroot/applicatives> recently to code-gen a multi-zip

Can the task be configured with proper dependencies such that Gradle can manage the parallelism?

The dependencies are configured.  The task in question is an Android DeviceProviderInstrumentTestTask.  What we are doing is adding a logcat listener before the task, and removing after the task.  So there is this external resource that is somewhat outside of gradle.  We need only one emulator logcat listener added at a time, as we want only the logcat generated from this test task.  There may be some alternative implementation, but I am trying to make config cache compliant with the minimum necessary changes.  Totally open to suggestions.

I was hopeful that a BuildServices maxParallelUsages would work for all of the task’s actions, but that’s not the case.  So in that sense it feels like I am configuring so gradle can manage the parallelism, but it ’s not working as expected.

If that would really be the case it is indeed a bug.
All actions should be affected, also `doFirst`.
Do you declare the `usesService` for those tasks?
Can you knit an MCVE that shows the problem?

Yes, we do declare usesService for this task.  I’ll try to prepare a MCVE.  I don’t see the problem in a small test project we use for plugin development, but it does show up in our large project, so may require some work to repro.

I considered trying to change this doFirst action to a task, and setup dependencies and finalizers such that ordering would be explicitly enforced.  A coworker said he ran into a gradle bug in the past such that task finalizers are not always respected across modules, so he thought this wouldn’t work either.  Still considering this idea though.

I realized after trying to reproduce this more, that I was just misunderstanding our logs and how gradle works.  The issue was not that multiple doFirst actions were running in parallel, it’s just that there is no guarantee about ordering.  doFirst actions run independently from other task actions.  So multiple doFirst actions from different tasks can run, and then other task actions will run, even if only one is allowed to run at a time.  It would be convenient to have concept of chained actions that must run together, but it doesn’t work that way.

So I don’t think there is a gradle bug here, just me not understanding how gradle works, and inheriting some code that had a hacky work around to avoid how gradle works wrt to doFirst actions and the rest of the actions for that task.

I was able to refactor all of this code to avoid the issue by moving more of the code to a build service so that the service is responsible for listening on the external emulator logcat resource, rather than trying to have tasks synchronize the adding and removing of listeners.   There was another unrelated blocker why it wasn’t implemented that way in the first place, but I found a way around it.

Thanks for the responses.

I think the thing is that several IDs can map to the same class, and Gradle only tracks the applied class. When using `hasPlugin` or `withPlugin`, Gradle uses an internal map of Ids to/from classes (n–1) to tell whether an applied plugin (by class) has a corresponding ID, but listing the IDs would need either making a choice as to which ID to use for a given class, or list all possible IDs.
That's my understanding at least.

I think so too.
There are some plugins that migrated from one plugin ID to another one, but still support usage of both afair.

I guess there's no way unless one looked into the Gradle internals

just to be clear - I don't really need the mappings or any knowledge of the plugin classes. I'm just looking for all the applied plugins ids.

Use-case - more or less an 'info' task which prints out all applied plugins.
I was looking into `buildEnvrionment`  task and I realized the core plugins aren't listed there and then started looking into alternatives..

The `buildEnvironment` task also does not show applied non-core plugins. It only shows the build script dependencies, but carries no information whether the plugins are applied or not, is which from the dependencies that can contain multiple.

With no state tracked I would not declare any inputs nor outputs

I'd be very interested in trying out your plugin, if I may. We're planning to sort the dependencies in a build with 500+ modules, so automation (even if it needed manual polishing) sounds very attractive

<@UABCKNV3K> do you agree that I shouldn't track inputs here? I wasn't quite sure about that. but the alternative was declaring the same file as both input and output and that feels weird

<@U035X1F32FQ> it'll be a couple of weeks till it's ready probably. need some legal stuff from work. but I'll ping this slack when it is

to be clear, the issue is only open sourcing it. I already have a little jvm app that does the work. we use it at Square

Yes, not tracking state is the best option

I think it doesn't exist, currently I am publishing to a local test maven repository

```tasks.testDependsOnPublishToMavenLocalTestFrom(projects.composeResources)```

If you need more details, I can share with you how that task is implemented

Thanks Javi.  That is unfortunate; seems like a commonish set up.  I think I'll look into the GradleRunner source and see if I can unravel how that might be accomplished.

You can add your other projects inside that "withPluginClasspath" by adding them to the `pluginUnderTestMetadata`  task's `pluginClasspath`.
```val additionalPluginClasspath by configurations.creating
dependencies {
    additionalPluginClasspath(project(":foo"))
}
tasks {
    pluginUnderTestMetadata {
        pluginClasspath.from(additionalPluginClasspath)
    }
}```
then `withPluginClasspath` inside the tests will have project ":foo" in it.

We try very hard to neither publish to nor consume from mavenLocal.  It has caused me problems many times

I assume `pluginClasspath.from(additionalPluginClasspath)` is additive?

Yes. `setFrom()` (or `from =` ) would replace the default value.

&gt; We try very hard to neither publish to nor consume from mavenLocal. It has caused me problems many times
Very wise actually, as it is not a pure repo, but also a caching proxy for Maven. :slightly_smiling_face:
But what you can always do too is to publish to a different local repository, just some path somewhere, for example in the `buildDirectory`.
Unless you need it for cross-build coordination, it is probably always preferable over `mavenLocal()`.

I must have missed something.  I have this, based on your snippet:

```configurations {
	additionalPluginTestClasspath
}

dependencies {
    ...

    implementation project(':hibernate-core')
	additionalPluginTestClasspath project(':hibernate-core')
}

tasks {
	pluginUnderTestMetadata {
		pluginClasspath.from configurations.additionalPluginTestClasspath
	}
}```
But still end up with test failures because:

```   &gt; Could not find org.hibernate.orm:hibernate-core:6.1.3-SNAPSHOT.```

Oh, indeed it doesn't work that way. If you already have the dependency in implementation, then it's already in the "plugin classpath". But that only means you can resolve plugin IDs from it, or use classes from the build scripts.

If you want to resolve JARs from your build, from the build driven by TestKit, then you could use a composite build (emit a settings.gradle with includeBuild)

You'd still need to publish it somewhere first, no?

That seems to be the essential limitation of TestKit here

No. Imagine, without TestKit, having to resolve Hibernate right from your other Hibernate project, but from another unrelated project; then you can use a composite build so you don't even have to "publish" a "snapshot". <https://docs.gradle.org/current/userguide/composite_builds.html>
Now, that other unrelated project can be driven by TestKit, it won't change anything :wink:
(assuming the included build is compatible with the version of Gradle you're using for TestKit's withGradleVersion ; otherwise you'll indeed have to publish somewhere)

I understand what composite builds are.  We use them already

Then either you don't understand what I'm suggesting, or I don't understand what your problem is / what you're trying to do :sweat_smile:

Um, sure.  That's why I said "I don't understanbd" :wink:

I do in fact understand what the problem is - TestKit cannot locally resolve other local modules

I do not understand what you are suggesting then I guess

How/where do you reference those modules? in `dependencies {}` of the build driven by TestKit?

I have a main module named `hibernate-core`

I also have a plugin that exposes some functionality of `hibernate-core` which it therefore needs as an implementation detail

The "test" project (aka user project mock) applies the plugin, but it also itself has a dependency on `hibernate-core` .  That project is defined as:

```plugins {
    id 'java'
    id 'org.hibernate.orm'
}

dependencies {
    implementation 'org.hibernate.orm:hibernate-core:6.1.0.Final'
}

hibernate {
    // DSL block
}```

As you can see, the test project "cheats" and uses a published version.  No problem, Gradle isolates classpaths

This should work, provided you also have a `repository {}` the resolve the dependency from.

The project itself is fine.  What does not work is the "local resolution" of `hibernate-core` relative to `id 'org.hibernate.orm'`

Notice the error message... it is not complaining about resolving the `.Final` reference.  It is complaining about resolving a `SNAPSHOT` reference

Isn't that because your plugin itself adds a dependency on hibernate-core using that SNAPSHOT version?

Anyway, this all just reinforces that TestKit does not support this

And I'll have to use a solution like Javi mentioned

If you wanted that to work, then you could have that "test" project itself be a composite build with the "outer" project, so it would resolve hibernate-core from that project (and if using the same Gradle version et al. almost all tasks should be up-to-date)

…or publish to an intermediary directory that you then use as a maven repository from the "test projet".

You mean separate the plugin and its tests?

Make the "mock" project itself a composite build with your own project that you are currently building / running tests.

So you are saying no, but meaning yes I think

I'd be happy to be proven wrong though - <https://github.com/hibernate/hibernate-orm>

Specifically - <https://github.com/hibernate/hibernate-orm/tree/main/hibernate-core>

And - <https://github.com/hibernate/hibernate-orm/tree/main/tooling/hibernate-gradle-plugin>

The "mock" project is simply a TestKit test project - <https://github.com/hibernate/hibernate-orm/tree/main/tooling/hibernate-gradle-plugin/src/test/resources/projects>

I'm certain I already saw such a setup in an open source project, but cannot remember which one.
Have the mock project have a settings.gradle file that includeBuild() the Hibernate root project (so you have Hibernate inside your Hibernate)

So you are saying that that test (mock) project needs to be moved out of the plugin project, effectively splitting the plugin from it its tests

Nope: just have the settings.gradle be generated dynamically with the appropriate path to the Hibernate project (the one for which tests are running)

That will only work if you move the test (mock) outside the plugin

For example, put the following in the test settings.gradle:
```includeBuild(System.getProperty("test.hibernate-project-path"))```
and add the following to TestKit's `withArguments()`: `"-Dtest.hibernate-project-path=" + Path.of("../../").toAbsolutePath()`

To make sure I understand your suggestion properly... you think I should:

1. Change the test's settings.gradle to use `includeBuild` with relative path up-to `hibernate-core`
2. Change the test's project.gradle to use `implementation project('hibernate-core')`
3. 3. Do the `pluginClasspath.from`stuff you mentioned earlier
correct?

No need for all that... the relative path is consistent

So I have:
```includeBuild "../../../../../../hibernate-core"```

But it does not like that, though the error is strange

```org.gradle.api.InvalidUserDataException: A path must be specified!```

The stacktrace shows it is trying to resolve the included build btw

Are you sure about that path? when I run the tests locally, it puts the test project inside /tmp/junitSomething/ so the includeBuild needs to reference the project with an absolute path

(I don't have failures without making any change though, so impossible to tell if my proposed changes (<https://gradle-community.slack.com/archives/CA745PZHN/p1665751862754669?thread_ts=1665747599.506999&amp;cid=CA745PZHN>) have any effect; except that they don't fail the build either)

You need to comment out :

```//    useSameVersion = false```

That effectively forces the test to use the published version.  Aka, its not testing anything

```diff --git a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle
index 20bc5d3..1f34c4b 100644
--- a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle
+++ b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle
@@ -27,7 +27,7 @@ dependencies {
 hibernate {
     // to get using the same version to work, we'd have to install hibernate-core into maven local prior to running these.
     // suck we won't be able to adequately test this part, but
-    useSameVersion = false
+    // useSameVersion = false
     enhancement {
         lazyInitialization( true )
         dirtyTracking = true```
```diff --git a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle
index e69de29..e823638 100644
--- a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle
+++ b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle
@@ -0,0 +1 @@
+includeBuild(System.getProperty("test.hibernate-project-path"))```
```diff --git a/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests.java b/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests
.java
index 16b07d2..b5d5903 100644
--- a/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests.java
+++ b/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests.java
@@ -36,7 +36,7 @@ class JavaProjectTests {
                                .withProjectDir( projectDir.toFile() )
                                .withPluginClasspath()
                                .withDebug( true )
-                               .withArguments( "clean", "compileJava", "--stacktrace", "--no-build-cache" )
+                               .withArguments( "clean", "compileJava", "--stacktrace", "--no-build-cache", "-Dtest.hibernate-project-path=" + Path.of("../../").toAbsolutePath() )
                                .forwardOutput();```
(repeat last change for each `withArguments()`, repeat changes for Kotlin tests)

```BUILD SUCCESSFUL in 56s
21 actionable tasks: 2 executed, 19 up-to-date```

Got pulled into one of those awesome "all Friday afternoon" meetings :wink:

I'll play around with this some more.

Thanks everyone

Not sure how to do this for any generic SourceSet; the below works for Java:
```    val javaExtension = the&lt;JavaPluginExtension&gt;()
    javaExtension.sourceSets.forEach { sourceSet -&gt;
        sourceSet.compileJavaTaskName
    }```

Seems like there’s a bunch of accessors exposed there:
```
    String getClassesTaskName();

    String getProcessResourcesTaskName();

    String getCompileJavaTaskName();

    String getCompileTaskName(String var1);

    String getJavadocTaskName();

    String getJarTaskName();

    String getJavadocJarTaskName();

    String getSourcesJarTaskName();

    String getTaskName(@Nullable String var1, @Nullable String var2);```

It looks like there’s a pattern - `compile` + `language`.
```    @Override
    public String getCompileTaskName(String language) {
        return getTaskName("compile", language);
    }

    @Override
    public String getCompileJavaTaskName() {
        return getCompileTaskName("java");
    }```

Perhaps grabbing the `destinationDirectory` from all org.gradle.api.tasks.compile.AbstractCompile tasks is more precise.
```/**
 * The base class for all JVM-based language compilation tasks.
 */
@DisableCachingByDefault(because = "Abstract super-class, not to be instantiated directly")
public abstract class AbstractCompile extends SourceTask {```

fyi, SourceSet. getCompileTaskName is used for cpp, swift as well (from Gradle sources).

There is not necessarily *the* task that compiles the sources, there can be multiple. But you should also not really do what you try to. Use the output of the source set as input for your byte code enhancement and you should also get automatically the necessary task dependencies.

Almost all cases where you want to set a manual `dependsOn` where not a lifecycle task is on the left side is a coffee smell actually.

<@URQ797WRW> That's not unreasonable and I tried that originally.  But it leads to other problems / difficulties.

At the moment this actually uses a do-last action to avoid up-to-date issues.

Using an actual task (iiuc) also means a new output directory which means lots of other tasks (jar, test, etc) need to get reconfigured

Ah, yeah, if you do the manipulation in-place, a `doLast` action is better of course.

But you then of course have to add code for any JVM language that could contribute. Java, Kotlin, Groovy, Scala, ..., any other that already exists or might be added in the future.

If you mean in terms of accessing the "compilation task", you are absolutely correct.  Making that SourceSet and compilation-task connection is the thing I am struggling with

<@U02S31Y7J2K> Sure, those methods "work" as I stated initially.  The problem is knowing ahead of time what the language is.  Once you know the language, sure, call `getCompileTaskName(String language)`

Now imagine you are writing a general use plugin - you do not *know* the language - it might be one of any

Maybe you can somehow just get all task dependencies and just attach your enhancement to all dependency tasks, just doing nothing if you don't find `.class` files in the output

Can a SourceSet really have multiple compilation tasks?

I know you can mix groovy and java sources, for example.  But they are compiled once iiuc

Groovy is a special case as Groovy supports joint compilation

Not sure if you have one or two tasks there

But for all other languages at least it should be one task per language

So taking a step back, do you see a better way to accomplish this?  Enhancing bytecode after compilation...

perhaps create an instrumentation task from each `AbstractCompile` task, hooking output to input?

To enhance it in the file in-place?
No, a `doLast` action is imho optimal in that case so that caching, up-to-dateness and so on are properly affected too.

If it does not have to be in-place the question is where it is needed.
If you need it everywhere the classes are used it might be indeed the best solution.
If you for example only need it in the test task, then you could add on out-of-place enhancement task and use that result for the test task for example.

Using a task is not really feasible.  It forces you to use a different "classes output dir"

<@URQ797WRW> No, unfortunately the enhanced classes need to completely replace the non-enhanced versions

Its really a "post compile" step in the truest sense

Then the `doLast` is most probably indeed the way to go.

Yes, that seems to be the consensus.  But that's what I am doing now and it has its own pitfalls which is what I initially asked about

I have to find the task(s) to which to apply the doLast (with some filtering, etc)

s/b `AbstractComile` instances with the filtering.

Are you sure all language plugins will extend it?

`tasks.withType&lt;AbstractCompile&gt;().configureEach`

<@U02S31Y7J2K> Again, its not filtering at the compilation level

that gets you all the compile tasks to which add the doLast to.

I still think you should maybe try to get all dependency tasks of the source set and just enhance all of them, no matter what type they are and just do nothing if no class files are found.

Or you need to support languages explicitly by getting their compile tasks and if someone uses another language they are lost and need to wait for you to support it

Ok, thanks <@URQ797WRW> and <@U02S31Y7J2K>

I'll just go with the "discrete language" support approach for now

I wouldn't depend on undocumented behavior that probably is a coincidence like that. If you really don't want to do that, just do not register the extension, why should you if the user should not configure it. Otherwise the user could also still configure it by type without the notifications. And if you really want it registered, just don't do it on plugin application, but for example when your own helper is called.

Usually if someone wants such notification, I recommend to just have one method in the extension that configures another object with the real properties and where you can do the notification at the end.

Hi, folks!
I wonder if this is fine to publish snapshots to the Gradle Plugin Portal?
At the moment, we publish work-in-progress releases to Sonatype snapshots channels: <https://oss.sonatype.org/content/repositories/snapshots/>
But switching to them requires proper adjustments in the project’s settings.

An advantage of the Sonatype repository is that I publish nightlies with the same version number, so it gets overwritten over and over.
Is that also possible with GPP?

I have (yes another) odd case I cannot quite figure out.  It has to do with source generation that is based on compilation.  I have 2 tasks:

• `generateJpaMetamodel` - uses the compiled project classes to generate some source
• `compileJpaMetamodel` - compiles the source generated by `generateJpaMetamodel`
This works fine if those 2 tasks are executed directly.  I'm trying to improve this by hooking them into the `classes` task but running into 2 problems:

1. `classes` is dependent on the actual SourceSet, but the SourceSet is configurable.  This leads to a chicken-egg issue I am unsure how to fix - specifically, how can I define a task dependency lazily based on a Property value?
2. In terms of inter-task dependencies, I am unsure how to avoid the circularity that comes up, although the circularity is implicit from somewhere (I believe from the use of FileSets related to compilation, but not sure).  Ideally I'd have:
    a. `generateJpaMetamodel`  depend on each language compile task (java, kotlin, etc)
    b. `compileJpaMetamodel` depend on `generateJpaMetamodel`
    c. `classes` depend on `compileJpaMetamodel`
I know that's a lot of info - thanks in advance for any pointers :slightly_smiling_face:

I decided to abandon using an initscript and have gone in another direction.

Assuming you’re referring to a custom task, the property type for a file would generally be RegularFileProperty.

It is indeed about a custom task or an extension, but configurable by the end-user.

a few options:
-have the user directly supply the file, e.g. prop.set(file(“someFile.txt”))
-hide some of that from the user e.g. prop.set(“someFile.txt”) for the extension (as a String), and then taskProp.set(prop.map { layout.projectDir.dir(it))})

Asking for a `String` when configuring an extension would be the most use-friendly – then mapping it to `RegularFileProperty` when passed to the actual task.
I’ll stick to that approach, thank you Chris!

You can also accept an Object and use `Project#file` if I understand you correctly.  Then the user could choose what to pass you

That’s pretty interesting – but I have bad feelings about it, I’m not sure why.

it’s a hold-over from the very-loosely-typed Groovy heritage of Gradle; cleanest to provide type-safety where possible.

People do still write builds using Groovy :wink:

Differently put, this was a recommended practice looong ago, but is bad practice now. ;-)

doing this for a custom repo via a Settings plugin that sets the `pluginManagement` repositories accordingly.

w/o a Settings plugin you can use beforeSettings in init scripts to setup repos as desired.

I think
&gt; using `.gradle`  instead of `.gradle.kts` for the scripts involved might also make a difference
indeed is your main or sole problem if I got it right.

Editing Gradle DSL build scripts in IntelliJ is still the only case where using the `-all` distribution instead of `-bin` is helpful, but only while editing the build scripts. There the source is included and you can navigate and complete better. This is just a work-around for a still unsolved IntelliJ shortcoming actually for which a ticket in YouTrack exists.

With Kotlin DSL build scripts it is different as there the source is automatically downloaded if necessary on first IDE sync.

Thank you. That was helpful.

I added one `.gradle.kts` script to the project (that is usually only based on Groovy scripts). That triggered the `-src` download on next sync :exploding_head: and afterwards the navigation worked. Also from the Java classes in all the subprojects.

I wonder if I can configure that manually somehow without having to add the `.gradle.kts`  script… ?

And… If I turn the “wrong” file into a “kts” I hit this one: <https://github.com/gradle/gradle/issues/21492>

This is just a little bit messed up… :confused:

Oh, never seen that one yet actually.

Regarding triggering the download manually, I doubt it.
I thin this happens during getting the dependencies for the kts within Gradle or something like that. I forgot the gory details from when I had a look at it.

maybe you could write an intellij plugin that does it somehow :smile:

You could also have some check whether you are in a Gradle sync and then download the sources or similar, but I don't think that makes much sense either.

I could probably download the sources manually, but I think I’ll still have trouble to link the correctly in IntelliJ. Because gradleApi() is this generated Jar and not the “real thing”. I think I tried in the past and it did not work. But I should give it another try.
Anyway, I have to research if there is an issue for this somewhere. Should work with Groovy DSL as smoothly as it works with Kotlin DSL.

This is the issue in which it is handled: <https://youtrack.jetbrains.com/issue/IDEA-203597/Bad-advise-on-using-Gradle-all-distribution|https://youtrack.jetbrains.com/issue/IDEA-203597/Bad-advise-on-using-Gradle-all-distribution>

If you use any of those Gradle API (<https://mvnrepository.com/artifact/dev.gradleplugins/gradle-api>) the source will always download properly because they are just normal artifacts. On the plus side, you can build against a different Gradle than the one used for building the project. With Gradle 7.x there are some minor issue when using some internal API, most notably `ProjectInternal#evaluate()` in a unit test but it works great. Note that you should use `compileOnly` or `compileOnlyApi` given the library should run in an environment where the Gradle runtime is provided.

My use-case is as follows: I'm developing a plugin that will compare 2 resources, both of these resources can either be a local resource (aka RegularFileProperty), or a remote resource (a file to be downloaded, and optionally extracted from a zip/tar/war/...).
The DSL currently looks like this:
```diffExtension {
    oldSchema {         // SchemaResource
        schemaUrl           // Property&lt;String&gt;
        username            // Property&lt;String&gt;
        password            // Property&lt;String&gt;
        requiresExtraction  // Property&lt;Boolean&gt;
        schemaFile          // Property&lt;String&gt;
        schema              // RegularFileProperty
    }
    newSchema {         // SchemaResource
        schemaUrl           // Property&lt;String&gt;
        username            // Property&lt;String&gt;
        password            // Property&lt;String&gt;
        requiresExtraction  // Property&lt;Boolean&gt;
        schemaFile          // Property&lt;String&gt;
        schema              // RegularFileProperty
    }
    outputDir               // DirectoryProperty
}```
you either define the `schema` property, or all the others, depending on where the file should be coming from. This is rather confusing in my opinion, so I would like it to look something like this instead:
```diffExtension {
    oldSchema {         // RemoteSchemaResource --&gt; somehow have a way to say to gradle that this is remote in this case
        schemaUrl           // Property&lt;String&gt;
        username            // Property&lt;String&gt;
        password            // Property&lt;String&gt;
        requiresExtraction  // Property&lt;Boolean&gt;
        schemaFile          // Property&lt;String&gt;
    }
    newSchema {         // LocalSchemaResource --&gt; somehow have a way to say to gradle that this is local in this case
        schema              // RegularFileProperty
    }
    outputDir               // DirectoryProperty
}```
Note that `oldSchema` and `newSchema` could take on the `RemoteSchemaResource` or `LocalSchemaResource` interchangeably.

Does it have to be that DSL-like?
Otherwise an option could for example be
```diffExtension {
    oldSchema.set(RemoteSchemaResource {
        ...
    }
    newSchema.set(LocalSchemaResource {
        ...
    }
    outputDir               // DirectoryProperty
}```

Or in the future when the compiler plugin is done:
```diffExtension {
    oldSchema = RemoteSchemaResource {
        ...
    }
    newSchema = LocalSchemaResource {
        ...
    }
    outputDir               // DirectoryProperty
}```

Or maybe with convenience functions instead of constructors
```diffExtension {
    oldSchema = remote {
        ...
    }
    newSchema = local {
        ...
    }
    outputDir               // DirectoryProperty
}```

`remote` and `local` have a parameter `Action&lt;RemoteSchemaResource&gt;` and `Action&lt;LocalSchemaResource&gt;` respectively and their body will create an instance, run the action against it and then return it.

For Kotlin DSL consumers you could maybe even do - if you really want to - define infix functions, so that it is like
```diffExtension {
    oldSchema remote {
        ...
    }
    newSchema local {
        ...
    }
    outputDir               // DirectoryProperty
}```

I was thinking about that `Action&lt;RemoteSchemaResource&gt;` way that you proposed. I'm just struggling to translate that to my extension object, which currently looks like this:
```public interface DiffExtension {

	@Nested
	SchemaResource getOldSchema();

	default void oldSchema(Action&lt;? super SchemaResource&gt; action) {
		action.execute(getOldSchema());
	}

	@Nested
	SchemaResource getNewSchema();

	default void newSchema(Action&lt;? super SchemaResource&gt; action) {
		action.execute(getNewSchema());
	}

	DirectoryProperty getOutputDir();

}```
what would the implementation of those configure Action methods be? Or do I define those on the `SchemaResource` Object itself instead of on the Extension?

Would have to think about it, but probably something like
```public interface DiffExtension {

	@Nested
	Property&lt;SchemaResource&gt; getOldSchema();

	@Nested
	Property&lt;SchemaResource&gt; getNewSchema();

    default SchemaResource remote(Action&lt;? super RemoteSchemaResource&gt; action) {
        RemoteSchemaResource result = new RemoteSchemaResource();
        action.execute(result);
        return result;
    }

    default SchemaResource local(Action&lt;? super LocalSchemaResource&gt; action) {
        LocalSchemaResource result = new LocalSchemaResource();
        action.execute(result);
        return result;
    }

	DirectoryProperty getOutputDir();

}```


alright, that looks like something I could try out. Thanks for the pointers :+1:

might not be what you want, but also possible:
```// buildSrc/src/main/java/Schema.java
public interface Schema extends Named {
}

// buildSrc/src/main/java/LocalSchema.java
public interface LocalSchema extends Schema {
  RegularFileProperty getSchema();
}

// buildSrc/src/main/java/RemoteSchema.java
public interface RemoteSchema extends Schema {
  Property&lt;URI&gt; getSchemaUri();
}

// buildSrc/src/main/java/DiffPlugin.java
public class DiffPlugin implements Plugin&lt;Project&gt; {
  @Override
  public void apply(Project project) {
    ExtensiblePolymorphicDomainObjectContainer&lt;Schema&gt; diffExtension = project.getObjects().polymorphicDomainObjectContainer(Schema.class);
    diffExtension.registerBinding(LocalSchema.class, LocalSchema.class);
    diffExtension.registerBinding(RemoteSchema.class, RemoteSchema.class);
    project.getExtensions().add(PolymorphicDomainObjectContainer.class, "diffExtension", diffExtension);
  }
}

// build.gradle
diffExtension {
  oldSchema(RemoteSchema) {
    schemaUrl = uri('<https://example.com/schema>')
  }

  newSchema(LocalSchema) {
    schema = file('example.schema')
  }
}```

if you don't want a `DomainObjectContainer` but only `oldSchema` and `newSchema` then you could still create methods like
```// buildSrc/src/main/java/DiffExtension.java
public interface DiffExtension {
  Property&lt;Schema&gt; getOldSchema();
  Property&lt;Schema&gt; getNewSchema();

  &lt;T extends Schema&gt; T oldSchema(Class&lt;T&gt; type, Action&lt;? super T&gt; configuration);
  &lt;T extends Schema&gt; T newSchema(Class&lt;T&gt; type, Action&lt;? super T&gt; configuration);
}

// buildSrc/src/main/java/DefaultDiffExtension.java
public abstract class DefaultDiffExtension implements DiffExtension {
  private final ObjectFactory objects;

  public DefaultDiffExtension(ObjectFactory objects) {
    this.objects = objects;
  }

  @Override
  public &lt;T extends Schema&gt; T oldSchema(Class&lt;T&gt; type, Action&lt;? super T&gt; configuration) {
    T schema = objects.newInstance(type);
    getOldSchema().set(schema);
    configuration.execute(schema);
    return schema;
  }

  @Override
  public &lt;T extends Schema&gt; T newSchema(Class&lt;T&gt; type, Action&lt;? super T&gt; configuration) {
    T schema = objects.newInstance(type);
    getNewSchema().set(schema);
    configuration.execute(schema);
    return schema;
  }
}

// buildSrc/src/main/java/DiffPlugin.java
public class DiffPlugin implements Plugin&lt;Project&gt; {
  @Override
  public void apply(Project project) {
    project.getExtensions().create(DiffExtension.class, "diffExtension", DefaultDiffExtension.class);
  }
}```
to make it work in a similar way

I thought about recommending a container, but thought it is not appropriate here, as he needs exactly those two instances, not more, not less, not differently named.
But the latter is also a good idea, giving the type like that, so it would be
```diffExtension {
    oldSchema(RemoteSchemaSource::class) {
        ...
    }
    newSchema(LocalSchemaSource::class) {
        ...
    }
    outputDir               // DirectoryProperty
}```
Or maybe it could also be made
```diffExtension {
    oldSchema&lt;RemoteSchemaSource&gt; {
        ...
    }
    newSchema&lt;LocalSchemaSource&gt; {
        ...
    }
    outputDir               // DirectoryProperty
}```
Or another option would be 4 methods
```diffExtension {
    remoteOldSchema {
        ...
    }
    localNewSchema {
        ...
    }
    outputDir               // DirectoryProperty
}```
and the remote and local of the same target exclude each other.

I gave it a shot and Gradle didn't auto-generate the `s/Class&lt;T&gt;/KClass&lt;T&gt;/` accessors for the extension like it does for other methods in the Gradle API :disappointed: so you'd have to write it in Kotlin to get 1 or 2 there

that's one thing that would work out of the box with the container, but yeah it does not do exactly what was asked for

writing your own functions for the `{remote,local}{Old,New}Schema` permutations is doable with this small number I guess

I was hoping it would do the `oldSchema(RemoteSchemaResource::class) { }`. I'm in the process or trying out this approach as we speak. It seems like the dsl now looks like the following:
```schemaDiff {
    oldSchema(RemoteSchemaResource::class.java, {
        schemaUrl.set("<https://some.uri>")
        username.set("myUsername")
        password.set("myPassword")
        requiresExtraction.set(true)
        schemaFile.set("filename.to.extract")
    })
    newSchema(LocalSchemaResource::class.java, {
        schema.set(schemaPath)
    })
}```
it's not horrible, but I can't say it looks amazing either :thinking_face:

I'll try with this suggestion as well, because I like that form a bit better: <https://gradle-community.slack.com/archives/CA745PZHN/p1666625683465489?thread_ts=1666625132.925799&amp;cid=CA745PZHN>

as always, you can move the lambda out of the parentheses
```schemaDiff {
    oldSchema(RemoteSchemaResource::class.java) {
        schemaUrl.set("<https://some.uri>")```
you can also write write the extension in Kotlin to add `KClass` overloads if you want (gradle-kotlin-dsl has a bunch generated for the Gradle API but I haven't figured out how to get it to do that for custom types)

with the other form, you'll end up with
```diffExtension {
    oldSchema.set(remote {
        ...
    })```
in Kotlin which I find more annoying, but YMMV

Currently, yes.
I hope they get it managed to write that Kotlin compiler plugin they are working on, so that the assignment form is possible. :slightly_smiling_face:

having tried both, I'll stick with the typed action with the lambda outside of the parentheses. Looks nicest indeed. Looking forward to that kotlin compiler plugin :crossed_fingers:

In any case, thanks for all the help and insights, much appreciated :slightly_smiling_face:

We have a plugin that is applied, wrapped in a
```rootProject.pluginManager.apply(OurPlugin::class)```
to only apply it to the root project

And a guard in the project
```require(target == target.rootProject)```


From what I can tell its similar to this issue, <https://stackoverflow.com/questions/29807622/gradle-artifactory-plugin-saying-cannot-cast-object-org-jfrog-gradle-plugin-ar> but I’m not sure how it happens. We’re not using buildscript, but we’re still getting our plugin loaded in different classloaders?

Apply is idempotent, Gradle won’t apply the same plug-in class more than once.  What does the extension registration code look like?

Possibly some classloader fun.  How do the sub projects get the plug-in class?  

That’s what I’m seeing. Unfortunately it is apply the plugin more than once

It will due to classloader - each sub project has a different class instance, tricking the root project into loading the plug-in multiple times.  What is the intent here - perhaps there’s a different way to accomplish it.