2012/11/15 Benson Margulies <bimargul...@gmail.com>: > I can see arguments on both sides of this question of how to pick the > logging ID. I'll start with my corner. > > The convention of having a logger for each class, named after the > class, is just that. A convention. It serves well in many cases. > However, in my opinion, it threatens to become a sort of cargo-cult > law of nature. > > The various logging frameworks all permit arbitrary names (with > separators) for loggers, and they permit it for a reason. Sometimes, > there is a good reason to control logging on an axis that is not class > names. > > I've had a few occasions where I really wanted to be able to control > logging on some other logical axis, so I created a logger with some > suitable name, and I used it in multiple classes. Just as in olamy's > proposal. > > This scheme makes it trivial for us to allow end-users to control > logging by plugin, since we don't need any additional framework, data > structure, or mapping. > > The other side of the coin, as I see it, is that developers also want > to do fine-grained logging control, and, in almost all cases, class > names serve well. So, something like Jason's scheme of using > conventional class names, but providing a mapping, would appear to > serve both needs. > > However ... the mapping in question seems to me to be inevitably tied > to the selection of one logging backend, unless we want to invent some > sort of slf4j-ish means of mapping. I am most familiar with log4j, so > I'll be concrete with the issue as it would arise there. If we use > class-name loggers, and provide a mapping that maps from G/AV to > packages or classes, something has to take this mapping and use it to > generate a log4j configuration. I presume that the same would apply to > logback or whatever else. > > That seems a lot of work to me. So, my opinion is that olamy's scheme > is better, because it puts the needs of end-users ahead of the needs > of devs.
can be easy to make that configurable with an option ? (default could be user oriented). As the stuff is done in only one class (DefaultPluginManager). > > However, if we only care about solving G/A/V control for actual > end-users of Maven, and not users of complex embeds, then my view gets > weaker. Once we choose a logging back-end for Apache Maven, it's not > going to be very hard to implement the control mapping for that one > back-end. > > So, weirdly, I find myself arguing against Jason on behalf of the use > case he's usually arguing for. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
