Can you make logging configurable?

[sofdes]

We're using your maven-buildtime-extension plugin where I'm working right now - very useful!

One issue we have is that we've a large multi-module build with lots of plugins, so when it reports at the end it spams our screens. Lots of people just want to se 'BUILD SUCCESS' and only a few need to know about all the plugin timings.

Can you add a configuration parameter to allow us to turn off logging, and/or allow us to specify thresholds we might be interested in reporting? Perhaps its also possible to report how long each module takes so we'd only be interested in reporting plugins if the entire module takes more than a certain time...

Right now we're suppressing the entire plugin using a build profile so would be great to have a bit of configuration built in.

Thanks

[timgifford]

Good idea. I've ran into a similar issue on my projects.

I'm curious about how you suppress the extension using a profile. I didn't know profiles supported the build/extension section.

Where would you expect to put this configuration setting? A property would work, but it isn't obvious or discoverable (without reading the code or help docs).

The extension section of the pom doesn't appear to support a section which would be the ideal place (if it existed).

I don't know if this would work, but should it only output the timings when Maven is called with -X,--debug option? I think the timing information is really only helpful in a debugging context and this wouldn't require pom changes by the want-to-see and don't-want-to-see team members.

Here are the options that I thought of summarized. I welcome other ideas. Thoughts?

Options

• Property
  • Con: Not discoverable without reading the code or docs
  • Pro: Able to pass the property in on the command line using -D
• Output for -X,--debug command line option
  • Con: Lots of additional information included
  • Pro: command line option doesn't require pom modification
• pom configuration
  • Con: constant changes to the pom between 'want-to-see' and 'don't-want-to-see' team members

[sofdes]

I favour properties as you can have a project-level property and override it with either command line or an entry in a user's settings.xml

As to discoverability - most IDEs provide auto-completion and you can show the configuration in your README.md file. I've done this in the 'config-generation-maven-plugin' plugin I wrote recently: https://github.com/sofdes/config-generation-maven-plugin

[sdaschner]

Hi there,

Since that version the default behavior doesn't show any information -- unless -X or buildtime.output.log is specified. I agree that logging that information spams the output for multi-module projects but not showing anything per default isn't too handy as well.

How about writing the information to a file in target/ and optionally choose to log it in the output? Different output formats would be cool too -- such as CSV, SQL for further querying...

If you agree I would fork & PR.

[jmhwang7]

Hi,

Just wanted to chime in. I think both having a properties file and writing outputs out in target/ would be awesome! I'm working on JSON output in a fork right now (would be awesome to eventually merge this in), and modifying/adding code in ExecutionTimingExecutionListener seems like it can get out of control if more output formats are added. Having 1 place that manages which outputs should be created (instead of having a ton of command-line options) would be amazing!

I'd also be willing to fork & PR.

[timgifford]

I'm moving this issue to 3.0 milestone. Publishing the data needs to be decoupled from the collection. I've taken an initial attempt in the publisher-spike branch. (Warning: it's hacky) Configuration would be defined in the plugin and extensions would use the plugin's configuration.

@jmhwang7 Let me know your thoughts. I know you're working on json output. Where are you planning to store the json? Is it just a file or are you planning on storing in Mongo or some other document db for trending?

[jmhwang7]

@timgifford I'm doing this a project for work, and am using Google's gson library (with some custom serializers/deserializers to get it into the format we want). The nice thing is that once the final object is a JsonElement, you can output it as a valid json string into a file, or store it somewhere else. Currently I'm doing both: writing out to a file for testing and for actual builds, sending it to a server and storing it into RethinkDb. RethinkDB IS trending, but I mostly chose it because it had a nice admin interface. :)

I would imagine we can provide a default JSON output, but maybe users can configure how they want their output by creating their own custom serializers/deserializers?

[timgifford]

Thx @jmhwang7. That makes sense.

Another option..we could also use the extensions.xml file for including the extensions. The third paragraph describes my hesitation to require the extension to be placed in the lib/ext folder.

http://takari.io/2015/03/19/core-extensions.html