Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of stephen.alan.connolly@gmail.com
 designates 209.85.212.173 as permitted sender)
MIME-Version: 1.0
Sender: stephen.alan.connolly@gmail.com
In-Reply-To: 
 <CA+U2j0rqq-OnvnGOhx9zEJm-bHnVX-x4zg+0kJmo5KHwcV33kw@mail.gmail.com>
References: <5406E4B8-BB5B-43AC-BCC0-AA0C0D01666A@tesla.io>
	<CA+U2j0rqq-OnvnGOhx9zEJm-bHnVX-x4zg+0kJmo5KHwcV33kw@mail.gmail.com>
Date: Tue, 11 Dec 2012 09:18:46 +0000
Message-ID: 
 <CA+nPnMwd4KXjE-CPi1HksPbQVXiN1WxJtKUdLtVNT=_T1BnKvQ@mail.gmail.com>
Subject: Re: Logback in Maven Core
From: Stephen Connolly <stephenc@apache.org>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=f46d04388e1b4758c104d0902b51

--f46d04388e1b4758c104d0902b51
Content-Type: text/plain; charset=ISO-8859-1

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.konermann@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" <jason@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.
> >
> >
> >
> >
> >
> >
>

--f46d04388e1b4758c104d0902b51--