This message was deleted.

The question is probably more why you want to do that. What is the use-case, what do you want to achieve, why do you need that?

This is to allow reconfiguring some of the tasks and optionally disabling some of them. We use it in sort of a "bootstrap".

Still sounds not quite right what you try. Also using something called

...Internal

is a very strong sign of code-smell. 🙂 If you want to configure tasks, why don't you just do it? And if you want to disable tasks after things ar configured, use

Task.onlyIf

closure which is evaluated at task execution time to check whether the task should run or not.

yeah..definitely code smell to me as well but 🤷 It's basically making this bootstrap task a pre-requirement for any tasks that are run. I.e. any gradle command line command you run, this task should be first. I don't think Task.onlyIf does this...

hey! I wrote this code originally – I was aware that using internal classes is not supported, but this was the only way I could find to force the execution of a task without breaking the configuration cache. Before that, we’d just add the desired task to

StartParameter

but I don’t think that’s any better.

tasks.configureEach { dependsOn(rootProject.mybootstrapTask) }

?

that’s adding this reference to thousands of tasks, while crossing project boundaries

I guess for that edge use-case crossing project boundary is ok

that’s not what we want though. We just want the task to run in parallel with the build

Hmm, what does the task do?

it deploys changes to the development environment

How about maybe doing it in a build service?

it’s an unconventional use of the Gradle build, but I found it to be surprisingly frequent, with a bunch of other companies using a similar hack

Hm, I'm out of simple ideas right now. Actually it sounds to me like you simply shouldn't do it, but have it as manual action the developer can invoke. I was about to suggest to use a custom gradle wrapper start script where the bootstrap task is hard-coded so it is always specified, but that of course only works from command line of course, not from IDE. If IntelliJ is your IDE, you could also configure some task to always run after sync or at other defined points using the

idea-ext

plugin. Another possibility for corporate projects would of course be a custom distribution. There you can basically change any Gradle implementation detail you like, including the possibility to inject such a bootstrap task.

yeah, we considered all that. None of them is ideal: • We’re supporting 100+ developers. Relying on all of them individually to run updates on a regular bases doesn’t work. Automatic deployment guarantees consistency of all development environments, with timely deployments and minimal maintenance cost. • Running as a background build through some other mean is disruptive, since we can’t run Gradle builds in the background without interfering the developer’s ability to run a build. We can attach it to hooks here and there, but we’ve found that running transparently during the build just works. • A custom distribution is a huge pain to maintain – especially if it’s just to implement something that belongs in the build configuration anyway.

Well, one death you have to die. 😄 You can also open a feature request to Gradle for supporting such a use-case. I'm just not sure how much priority it will get. 🙂

yeah, I should’ve done that originally 😬. Let me try…

But to me it sounds a bit like out-of-scope of what Gradle is for. But that's just my personal feeling. 🙂

yeah, I understand