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

Gradle Community

I would probably follow the usual good practice to have one logger per class and hope that Gradle at some point finally provides a way to properly configure the logging fine-grained.

your idea is probably the best one I've seen Jakub :) The default Gradle logger's output is quite confusing without the plugin-id tag and task/project path that you've added

Thanks. :slightly_smiling_face: But I’m concerned about keep using it.
Plugin is about to get a new, longer name. This and the project path…

```[IntelliJ Platform Gradle Plugin :subproject:verifyPluginConfiguration] The following plugin configuration ...```
72 characters of prefix.

tbh that seems fine to me - but maybe the plugin ID would be shorter, and easier to search, and easier for users to understand where the log message is coming from?

Also, such a log appears in the `&gt; Task :subproject:verifyPluginConfiguration` section, so maybe it’s redundant?

with task paths you could leave out the plugin name/ID - the task path should be enough

```const val PLUGIN_NAME = "IntelliJ Platform Gradle Plugin"
const val PLUGIN_ID =   "org.jetbrains.intellij.platform"```
Same length :slightly_smiling_face:

it's only IntelliJ that groups the logs, right? Running in CI or from cmd line the task path could still be useful

though it is possible to tell GitHub to <https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#grouping-log-lines|group logs>. I remember playing around with that once, getting Gradle to emit the correct start/end group tags.

<https://github.com/JetBrains/intellij-platform-plugin-template/actions/runs/7190787054/job/19584472747#step:7:238>

```&gt; Task :jarSearchableOptions
[gradle-intellij-plugin :jarSearchableOptions] No searchable options found. If plugin is not supposed to provide custom settings exposed in UI, disable building searchable options to decrease the build time. See: <https://plugins.jetbrains.com/docs/intellij/tools-gradle-intellij-plugin-faq.html#how-to-disable-building-searchable-options>```

ah yeah, okay! So maybe it does make sense to leave out the path. Unless there are lots of logs... or Gradle is running stuff in parallel...

Dropping this path could make my life easier as I won’t have to pass the context everywhere.

Don't forget configuration cache with which all tasks are going to run in parallel if they do not have a dependency or ordering constraint

Ok, I’ll switch to Gradle’s logger then and prefix all messages with the plugin ID.

Each task’s configuration I already start with something like:
```Configuring task: $name```