OK. In the absence of anyone else giving some numbers I have been running some tests.
I have been comparing 3.0.4 with logback (using git hash 7f9e280522379fc0f3ac09f4d81e8188cdb54192) and log4j (using git hash 0f71ae559e19aa3eb5e4f5c981d9e20e63cc2e3e) The first test was building GIT hash of e20a42cbd871de86e9e77fe9900e1a2829177125 of Jenkins with the following command line: mvn -o -DskipTests clean verify [Testing a long build under normal conditions] The consistent times (i.e. repeated runs after discarding the first) are: 3.0.4: 1min18sec logback: 1min13sec log4j2: 1min34sec The second test was building GIT hash 85dd6e37456d30d2661e10b044efa9036c528023 of jszip-maven-plugin (@jszip.org) with the following command line: mvn -o -X clean verify -DskipTests -Dinvoker.skip [Testing heavy logging] 3.0.4: 12.1sec logback: 12.2sec log4j2: 12.5sec Notes: 1. With -X logback spews forth a lot more shite at the end of the build. This is just an observation and I assume it will be tidied up before there would be a release if logback is chosen. 2. I am unsure if the log4j2 branch I tested is current with regard to the regression fixes in the logback branch... or even if I have picked the correct logback branch. 3. Slightly concerned with the jenkins build time with log4j2... that looks like more than a 5% regression. It would be good if somebody else can confirm this result as it could be the background gremlins struck at the time I was trying the log4j2 builds On 11 December 2012 09:18, Stephen Connolly <steph...@apache.org> wrote: > Given that some people are already confused as to what the exact question > is > I think we should clarify exactly what is the decision that is being asked. > > There has already been a decision to use the slf4j API for logging within > core. > > * The vast majority of plugins will still use the Maven Log interface for > their logging. > > * A small limited number of plugins with specific needs will use the > slf4j API that > is exposed by core directly, but those plugins will have to do some > work in > order to ensure that they work with Maven pre 3.1.0 as well as Maven > post 3.1.0 > > My understanding is that they will have to add a slf4j implementation > to their > dependencies... on Maven 3.1.0+ the implementation will be ignored as > the > slf4j-api that they see on their classpath will already have been > initialized with > core's implementation. On Maven pre-3.1.0 their slf4j-api will be > initialized and > find their slf4j implementation. > > * A smaller subset of plugins need to control the slf4j implementation > and > cannot have a different implementation. Those plugins will have to add > a > metadata flag requesting a classloader that is isolated from core's > slf4j API. > Such plugins might be redirecting log output for processing, or some > other > need that we have not foreseen. > > On Maven 3.1.0 if the metadata flag is not present the plugin will > likely be > borked and a newer version with the metadata flag will need to be > released > [Though the precise behaviour in the absence of this flag is yet to be > defined] > When the flag is enabled, the Maven Log interface will be the way the > plugin > is required to route the information it wants logged to the user > through to > the user. > > On Maven pre-3.1.0 things will be as they always were, i.e. the Maven > Log > interface is the way we prefer information to be logged through to the > user. > > What is being discussed now is which *implementation* to use for the Maven > CLI > commands by default in core starting with Maven 3.1.0. > > There are a number of possible implementations: > > * SLF4J Simple was initially considered. This is a very limited logger > but would > be able to produce logging output formatted the same as Maven currently > provides. *However* there is a regression caused for some of the > integration > tests when using SLF4J and fixing those issues currently produces > performance > regressions as well as the current uncertainty as to whether those > fixes will > be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J Simple > is currently being rejected on technical grounds (but if sufficient > developers > really want to go with the "we don't want to choose a specific > implementation" > choice, this is the implementation you would be selecting. > > * Logback is being proposed by Jason. AFAIK this implementation passes on > the > technical criteria. In other words no failing integration tests and no > significant > performance regressions. > > * Log4j2 has been championed by Olivier. AFAIK this implementation passes > on > the integration tests. I am not sure of the performance technical test. > One should > note that Log4j2 is a new implementation and is not Log4j > > I hope that Olivier or somebody else can confirm the integration test > status of Log4j2 > as a back end implementation and provide information on the performance > status > of Log4j2. > > To my knowledge no other SLF4J implementations have been proposed, but if > there are others that people want considered please provide an update here. > > The primary concern that Maven committers should apply is the technical > merit of > any proposed implementation. > > An implementation should be able to pass all the integration tests and not > produce > a significant performance regression. > > Developers should not concern themselves with the licensing terms of the > implementation provided that the implementation is available under one of > the > ASL compatible licenses (i.e. Category A or Category B). If a Category B > licensed > implementation is chosen then for legal reasons the PMC must approve the > use > of that dependency. (Personally speaking, if that decision is purely based > on > technical grounds, I do not see why the PMC would object) > > Maven Committers can use other criteria in making their decision. Just > ensure > that the technical merit is the primary criteria and do not make the > decision based > on Licensing. > > If you are not a committer, your input is still wanted and welcome. We > want this > decision to be one embraced by the whole community. > > -Stephen > > > On 11 December 2012 07:14, Ansgar Konermann < > ansgar.konerm...@googlemail.com> wrote: > >> Hi, >> >> please go for logback. I really wondered why slf4j was initially chosen at >> all, given logback is available and mature. We've been using logback at >> work in production for quite some time now and are very pleased. So yes, >> using logback in Maven is fine. >> >> Regards >> >> Ansgar >> Am 11.12.2012 03:33 schrieb "Jason van Zyl" <ja...@tesla.io>: >> >> > Hi, >> > >> > I looked around a bit more today and I don't think SLF4J Simple is >> viable >> > long term, I don't want to patch it anymore as I would have to do a >> day's >> > work to make changes that keep the performance levels up, get it >> reviewed >> > and released, and I honestly don't think it's worth it anymore. I would >> > rather spend my time building out the plugin test cases and help to >> finish >> > the classloader blocking of SLF4J. I don't mind spending time getting it >> > all working but I don't want to waste my time on an implementation we're >> > going to toss. >> > >> > After a conversation with the PMC it will require a vote to accept >> Logback >> > which is EPL but I wanted to ask committers and interested users about >> > using Logback. I believe Logback is the best choice as it's the most >> mature >> > and battle tested implementation because once it goes in it's likely not >> > ever to come out. Many of us are users and have integration experience >> with >> > Logback and it's what I use everyday for logging in all my other >> projects >> > and I've been a happy user for years. I see Logback as best of breed and >> > widely adopted including 8 projects at Apache. >> > >> > There's no point in asking the PMC to vote on the acceptance of Logback >> if >> > it's not acceptable by the community. If there are interested users I >> would >> > really like to hear what you think because you're the ones who will >> have to >> > live with the choice that is made. >> > >> > Thanks, >> > >> > Jason >> > >> > ---------------------------------------------------------- >> > Jason van Zyl >> > Founder & CTO, Sonatype >> > Founder, Apache Maven >> > http://twitter.com/jvanzyl >> > --------------------------------------------------------- >> > >> > To do two things at once is to do neither. >> > >> > -- Publilius Syrus, Roman slave, first century B.C. >> > >> > >> > >> > >> > >> > >> > >
