Hi,
I'd like to open a discussion about the logs printed by Gradle to the
console.
For example, I'm taking a small example of a ZIP task that I'm currently
having a problem with. I'm running a Gradle script that is supposed to
compile a JAR file, and then ZIP it with all its dependencies. One of the
files is missing in the result ZIP by some reason, and I'm trying to
understand why - from the logs.
task zip(type: Zip) {
into('utils.meteo/lib') {
from configurations.runtime, 'build/libs'
}
into('utils.meteo/bin') {
from 'dist/bin'
}
}
Quiet logs are quiet - they only say that the task was successfully
executed - they are perfectly fine, and are not supposed to help me.
Logs printed with "-i" (at INFO level) explain to me how the modules depend
one on another, and why and what gets executed. It's a little better, but
it does not help with the task - I have no idea what is being zipped (and
more importantly - what's not):
:utils.meteo:zip
Executing task ':utils.meteo:zip' due to:
Output file trunk/utils.meteo/build/distributions/utils.meteo-0.1.zip for
task ':utils.meteo:zip' has changed.
Output file trunk/utils.meteo/build/distributions/utils.meteo-0.1.zip has
been removed for task ':utils.meteo:zip'.
BUILD SUCCESSFUL
Ok, may be with debug logs I'll have more info?
15:34:45.499 [INFO]
[org.gradle.api.internal.changedetection.DefaultTaskArtifactStateRepository]
Executing task ':utils.meteo:zip' due to:
Output file trunk/utils.meteo/build/distributions/utils.meteo-0.1.zip for
task ':utils.meteo:zip' has changed.
Output file trunk/utils.meteo/build/distributions/utils.meteo-0.1.zip has
been removed for task ':utils.meteo:zip'.
15:34:45.499 [DEBUG]
[org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] task
':utils.meteo:zip' is not up-to-date
15:34:45.500 [DEBUG]
[org.gradle.api.internal.changedetection.DefaultFileCacheListener]
Invalidate cached files for file
'trunk/utils.meteo/build/distributions/utils.meteo-0.1.zip'
15:34:45.501 [DEBUG]
[org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter]
Executing actions for task ':utils.meteo:zip'.
15:34:46.194 [DEBUG]
[org.gradle.api.internal.changedetection.DefaultFileCacheListener] Can
cache files for file
'trunk/utils.meteo/build/distributions/utils.meteo-0.1.zip'
15:34:46.303 [DEBUG]
[org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter]
Finished executing task ':utils.meteo:zip'
15:34:46.303 [DEBUG] [org.gradle.execution.DefaultTaskGraphExecuter]
Timing: Executing the DAG took 5.442 secs
15:34:46.305 [LIFECYCLE] [org.gradle.BuildResultLogger]
15:34:46.306 [LIFECYCLE] [org.gradle.BuildResultLogger] BUILD SUCCESSFUL
No, no luck. I have to devise a way to print a list of files matching the
masks I've provided to the ZIP task. Now, I don't expect to get a complete
list of files - it may probably be too lengthy. But I'd like at least to
understand what masks matched my files and what masks matched no files
(because they are wrong).
BTW, lately, I was working with a large enterprise build based on BuildR,
and it was very difficult to maintain because of messy and very uclear
logs. Gradle is usually better in that respect, but not always.
My vision of the logging in a build script, by log levels:
- very quiet - only status - OK or FAIL
- quiet - default - status of executed modules and major tasks - here
Gradle is just perfect.
- info - what dependencies were required, what was compiled and with
what options, what was copied and where, what was zipped - everything I
would need in the morning after running a nightly build in order to
understand what went wrong with my build without re-running it again.
- debug - as much information as possible to debugging Gradle internals
- but I should never need it except for reporting a bug to Gradle
developers.
There is a nice page that discuss logging in Gradle -
http://gradle.org/logging
and I think it lacks such kind of a vision for what and when should be
logged.
It's especially important for the most basic tasks that are reused
extensively - like ZIP in this example.
Regards,
Andrew Schetinin
