In a Jenkins build I would never want more than lifecycle because the impact by logging debug or info level from slave is a serious performance hit and the size of the build output is far too much.
However if there is a logfile in the workspace with debug level it can be scrutinised to diagnose some problem and then be deleted before a next build or even after build is successful.
gradle.loglevel default is info
If the logfile cannot be created an error is logged to console and logging stops but build continues
If a logback.xml is present in build directory it governs the logging to file.
If logback.xml or log4.properties can lead to problems then support a subset that only controls the appender configuration and loglevel of different categories.
Yes, of course, you have to differ needs of real users and developers of the plugins to get different informations. We want the ordinary user of the build system to get less information he needs to successfully finish the build. This is in general only the progress or any errors, which occurred during the build.
If an error occurs you need a possibility to understand what’s going on under the hood if you are the developer of the plugin and maybe you faced a bug. Because the following up builds don’t work on the same environment necessarily (the build itself created some artefacts, which are not built anymore due to they are up to date), it would be important to get these informations in the build where they occur. Therefore logging into a file would be importan to have a possibility for kind of “post mortem analysis”.
The second point you have written, we have implemented for some tasks (e.g. test tasks) by iterating the tasks and setting the system property of the configuration to be used (e.g. log4j.configfile). This works for us.
afaik there is no inbuilt solution so far. We have moved our generators to an own javaexec - jvm, so we can configure our logging the way we like and performance of calling a seperate vm is ok as long as having the up-to-date detection in the gradle vm itself