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

Gradle Community

`file` in your code is actually `this@allPublishableArtifacts._file`, so it has a reference to_ `this@allPublishableArtifacts` which then cascades.
Store `file` to a local variable outside the `doLast` and I think it should be compatible.

For the second trace, I'd guess it is either `api` or `config`, but you didn't specify what those are.

Btw. why do you get the publication by name, when you alread have it in `this`?

And `project.plugins` should not be used, according to its JavaDoc, but instead `project.pluginManger.withPlugin("maven-publish") { ... }`. Especially `withType` does not make too much sense as a plugin cannot be applied multiple times.

Yes! Using copy of File outside of `doLast` decreased amount of errors to 6.

Thanks to
```project.pluginManager.withPlugin("maven-publish")```
I just don't like the string constant instead of class name, but it is probably safer.

&gt;  Btw. why do you get the publication by name, when you alread have it in `this`?
Hard to say, it is 2 years old code :slightly_smiling_face:
I probably wanted to make it clear, because there is too much this, I like more when there is lambda parameter instead of this.
But yes I can use proper `this@all`

&gt; I just don't like the string constant instead of class name, but it is probably safer.
Yeah, well, whatever works for you. Just saying it is not the recommended way. :slightly_smiling_face:

You can use `this@all`, or you can do `all publication@*{` and then* `this@publication`, or you can do `val publication = this` right after the opening brace and then use `publication` later.

And rest of 6 issues.
the config has reference to
```project.providers```


Or
```also { publication -&gt;

}```
or
```let { publication -&gt;

}```

Yeah, well if `config` has reference to `project` and as you have `config` in `doLast`, you have your last break point. :slightly_smiling_face:

Not directly to project, but to providers, it is allowed to use them in Task, but probably only via

```@get:Inject
abstract val providers: ProviderFactory```

Well, hard to say without seeing its code :slightly_smiling_face:

Hmm, it looks that this did not help, it still failing on 6 issues.
It looks like issue is that lambda itself has reference to enclosing class.

I know where is problem :slightly_smiling_face:

`api` and `config` are fields of enclosing class

So, issue is just in the color :slightly_smiling_face:
This is wrong

Thanks a lot. Solution is always so easy, why I always spent whole day on it :slightly_smiling_face:

Well, like with everything, it's just easy if you know the solution already. :smile:

Yes :slightly_smiling_face:


And reference to
```project.providers```
 is completely fine. I can keep it there and it still works.