The generator since long supports the -v command line switch. Turning this switch on will make the generator print out lots of messages and internal data while going through configurations and running jobs. This is one of the first and easiest means to inspect the workings of the generator as it proceeds, and has been very helpful in tracking down issues with custom configurations and job delivery.
But as more and more functionality went into the generator the amount of verbose logging has grown tremendously. You had to redirect its output to a file and then wade through it in a suitable editor or viewer, in order to gather the pieces of information you were actually interested in. So if you just wanted to know which qooxdoo classes were brought together to make up your application, or which of those classes made it into which part (if you were using parts), this could be a challenge although the information was readily available.
On top of the known -v switch the generator now offers two more features around verbose logging. A new command-line switch, -w/–config-verbose, has been introduced to separate verbose logging of all the generator activities before actually running a given job. (As this is mainly processing of the configuration file and its directives, hence the long name of the option). On the other side, the scope of -v has been restricted and now specifically applies to running the jobs themselves.
The other feature is that you can specify log4j-like module patterns of the generator, and then verbose logging will be restricted to these modules and their functions only. It is implemented as a sub-key of the “log” config key, namely as log/filter/debug. This key takes an array of module patterns, similar to the class patterns of other config keys. If a function now tries to log a message verbosely, its module path is matched against all of the given patterns, and the message is only printed on a successful match. E.g
"log" : { "filter" : { "debug" : [ "generator.code.PartBuilder.*" ] } }
will only allow functions from the generator.code.PartBuilder module to be printed. This greatly reduces verbose log output and allows you to focus on the areas you are interested in. I think the future will see some common, pre-defined filters that can be easily added to a job so you are not forced to go down to the basic config key level to enable them.
Update: I’ve added two includer jobs, “log-parts” and “log-dependencies” to the application.json (via base.json). You can use them in your own jobs by adding them to the “extend” key. For example, adding
“source-script” : { “extend” : [ "log-dependencies" ] }
to your config.json will print extra information about class dependency analysis when you run ‘generate.py source -v’
.