Stephen, Thanks for the complete explanation, I'm a little logging beleaguered :-)
On Dec 11, 2012, at 4:18 AM, 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. >>> >>> >>> >>> >>> >>> >> 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.
