is there a preferred way to conditionally register a task based on whether another task exists?

unsure on the conditional registration; in the past I’ve addressed this by having the task always registered and conditionally enabled.

+1. Immediate reaction would be something like so:

tasks.register("foo")

tasks.configureEach {
  if (name == "foo") {
    // Gradle fails here
    tasks.register("bar")
  }
}

But this doesn't work.

but if a task you depend on doesn't exist then your task won't work and shouldn't be listed in tasks right?

Something like concurrent mutation exception or something. You add to a list while iterating it.

Tasks are generally registered by a plugin, so you should use

pluginManager.withPlugin

instead.

I'm adding a task based on whether a publication is configured. I actually think this will work...

tasks
      .withType(PublishToMavenRepository.class)
      .stream()
      .filter(task -> task.getName().startsWith("publishMavenPublicationTo"))
      .toList()
      .forEach(task -> {
        var repository = task.getRepository();
        tasks.register(repository.getName() + "ArtifactPath", ArtifactPathTask.class, t -> {
          t.getDirectory().set(project.getLayout().dir(project.provider(() -> new File(repository.getUrl()))));
          t.getProjectName().set(project.getName());
          t.getProjectGroup().set(project.getGroup().toString());
          t.getProjectVersion().set(project.provider(project.getVersion()::toString));
        });
      });

You should not use stream, filter and forEach

but didn't we just discuss how that wouldn't work?

And you should use the maven publish extension and extract the repositories because the publish plugin creates the tasks based on the extension

you do realize how it sounds like you're contradicting yourself right now

Nope 😎😂

"use configureEach" but martin says "use configureEach doesn't work" "yes but martin uses configureEach. use configureEach" this is my interpretation of the conversation

You should use this code:

pluginManager.withPlugin("maven-publish") {
  val publishExtension = extensions.getByType<PublishingExtension>()
  publishExtension.repositories.withType<MavenArtifactRepository>().configureEach {
}

Yea, react to the "repositories" instead of reacting to the "tasks"

iterating though the tasks realizes them.

Not if you

.configureEach {}

, right?

Yeah, but configureEach is lazy :) And forEach is not.

Yup

forEach{}

and all collection APIs are verboten

And you should not register a task inside configureEach of another task.

Completely tangential but I realized recently that

.all{}

is on both

NamedDomainObjectContainer

and

Iterable<T>

so depending your compile type, it will do things lazy or eagerly , differently, fun times! 😄

Hm? All is eager

Yea even more fun, sorry

No:

This method is a terminal eager operation. It will cause the realization of all elements of this collection.

yea but if you add after the fact, the closure gets called (I think?)

Yeah, it calls any closures immediately, even configureEach

tasks.all {
  println("${it.name}")
  true
}

tasks.register("foo")

This prints("foo")

What not, of course not

Yea

So adding new elements after calling Java

all

won't contain/realize the new elements.

Yea, this is my mental model as well. It was just fun to bump into that

read as KGB source code 😛

Well, KGP also uses coroutines for custom "stages" internally to not use `Provider`s... I agree, they are annoying to use, but still.

ugh... that won't exactly work because I'm also dependent on the output of the task... which is why I was using the task...

Thats okay, just use

tasks.named("publishMavenPublicationTo" + name)

and the providers

(insert repsonse to subsequent question about casing), I'll get it... but in the mean time I have to go hastle my apt complex about their rent issues in this ... transitional time 😞

And local vs remote: use the url

Yep, got a parse the URL though to make sure its scheme isn't starting with HTTP which I'm sure From a simplistic standpoint is not sufficient but given it's a convention plug-in it should be enough

What do you mean with

parse

? You can just use URI.getScheme, but yeah, you need to "parse" the scheme or just check if the scheme is http/https

I need to parse the scheme. That's what I mean. If this wasn't going into a shared convention plug-in, I would probably make a ton of effort to figure out which things are considered valid local versus valid remote, but I'm not going to do that

> Well, KGP also uses coroutines for custom “stages” internally to not use `Provider`s I think its because the programming model of coroutines fits the gradle environment. Coroutines is the superior programming model for gradle plugins imho.

Afair

register

within

someTasks.configureEach

does not work (if task-configuraton avoidance is not broken) as the closure is called too late to register a new task, but you could still use

create

instead of

register

within the

configureEach

.