On 02/12/2011, at 1:02 AM, Andrew Schetinin wrote:
> 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
You could do something like this:
zip {
eachFile { fileDetails -> logger.info("Including $fileDetails.file as
$fileDetails.path") }
}
This is a general strategy in Gradle: often there are events you can receive to
do your own logging when the built-in stuff doesn't work for you.
> . 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).
This is a good idea. Could you add an 'idea' posting to the forum, so we can
track this?
>
> 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
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
