You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@tesla.io> on 2012/12/11 03:32:45 UTC
Logback in Maven Core
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.
Re: Logback in Maven Core
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
+1 for logback
--
Regards,
Igor
On 2012-12-10 9:32 PM, Jason van Zyl wrote:
> 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.
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Dec 12, 2012 at 8:38 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Another criteria that people should pay attention to is whether the
> implementation supports Mapped Diagnostic Contexts
> http://logback.qos.ch/manual/mdc.html
>
> AFAIU this may rule out JUL as a serious implementation... In other words
> when we want to start using MDCs to make it easier to navigate the logs, if
> the implementation we choose does not support MDCs then we would need to
> choose again.
>
> According to the slf4j website logback and log4j support MDCs (I am
> presuming that log4j2 does also therefore)
>
Yes, please see
https://logging.apache.org/log4j/2.x/manual/thread-context.html
Gary
>
> On Tuesday, 11 December 2012, Stephen Connolly 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 th
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
Another criteria that people should pay attention to is whether the
implementation supports Mapped Diagnostic Contexts
http://logback.qos.ch/manual/mdc.html
AFAIU this may rule out JUL as a serious implementation... In other words
when we want to start using MDCs to make it easier to navigate the logs, if
the implementation we choose does not support MDCs then we would need to
choose again.
According to the slf4j website logback and log4j support MDCs (I am
presuming that log4j2 does also therefore)
On Tuesday, 11 December 2012, Stephen Connolly 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 th
>
Re: Logback in Maven Core
Posted by Jason van Zyl <ja...@tesla.io>.
I'll let folks focus on their evaluations and I'll work on the sample plugins and classloader isolation.
On Dec 12, 2012, at 9:23 AM, Stephen Connolly <st...@gmail.com> wrote:
> On Wednesday, 12 December 2012, Daniel Kulp wrote:
>
>>
>> On Dec 12, 2012, at 8:45 AM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>
>>> Another criteria that people should pay attention to is whether the
>>> implementation supports Mapped Diagnostic Contexts
>>> http://logback.qos.ch/manual/mdc.html
>>>
>>> AFAIU this may rule out JUL as a serious implementation... In other words
>>> when we want to start using MDCs to make it easier to navigate the logs,
>> if
>>> the implementation we choose does not support MDCs then we would need to
>>> choose again.
>>
>> Well, if have to write our jul formatter to handle the WARN -> WARNING
>> thing, we could handle this as well. slf4j-jdk14 sticks a
>> BasicMDCAdapater on there that just stores the context in a ThreadLocal.
>> Nothing uses it, but the data would be there. Our formatter could grab
>> the MDC and use it if we wanted it to.
>
>
> I cannot recall if JUL guarantees that the formatter will be called from
> the same thread as the log record was generated on.
>
> If it maintains that as an invariant then we could rescue JUL as a possible
> implementation
>
> If not then I fear it us dead in the water
>
> -Stephen
>
>>
>> Not saying that we SHOULD do this, just that we could, particularly if we
>> did write a formatter.
>>
>> Dan
>>
>>
>>
>>
>>>
>>> According to the slf4j website logback and log4j support MDCs (I am
>>> presuming that log4j2 does also therefore)
>>>
>>> On Tuesday, 11 December 2012, Stephen Connolly 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
>>> --
>> Daniel Kulp
>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>>
>>
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.
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
On Wednesday, 12 December 2012, Daniel Kulp wrote:
>
> On Dec 12, 2012, at 8:45 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> > Another criteria that people should pay attention to is whether the
> > implementation supports Mapped Diagnostic Contexts
> > http://logback.qos.ch/manual/mdc.html
> >
> > AFAIU this may rule out JUL as a serious implementation... In other words
> > when we want to start using MDCs to make it easier to navigate the logs,
> if
> > the implementation we choose does not support MDCs then we would need to
> > choose again.
>
> Well, if have to write our jul formatter to handle the WARN -> WARNING
> thing, we could handle this as well. slf4j-jdk14 sticks a
> BasicMDCAdapater on there that just stores the context in a ThreadLocal.
> Nothing uses it, but the data would be there. Our formatter could grab
> the MDC and use it if we wanted it to.
I cannot recall if JUL guarantees that the formatter will be called from
the same thread as the log record was generated on.
If it maintains that as an invariant then we could rescue JUL as a possible
implementation
If not then I fear it us dead in the water
-Stephen
>
> Not saying that we SHOULD do this, just that we could, particularly if we
> did write a formatter.
>
> Dan
>
>
>
>
> >
> > According to the slf4j website logback and log4j support MDCs (I am
> > presuming that log4j2 does also therefore)
> >
> > On Tuesday, 11 December 2012, Stephen Connolly 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
> >--
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
Re: Logback in Maven Core
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 12, 2012, at 8:45 AM, Stephen Connolly <st...@gmail.com> wrote:
> Another criteria that people should pay attention to is whether the
> implementation supports Mapped Diagnostic Contexts
> http://logback.qos.ch/manual/mdc.html
>
> AFAIU this may rule out JUL as a serious implementation... In other words
> when we want to start using MDCs to make it easier to navigate the logs, if
> the implementation we choose does not support MDCs then we would need to
> choose again.
Well, if have to write our jul formatter to handle the WARN -> WARNING thing, we could handle this as well. slf4j-jdk14 sticks a BasicMDCAdapater on there that just stores the context in a ThreadLocal. Nothing uses it, but the data would be there. Our formatter could grab the MDC and use it if we wanted it to.
Not saying that we SHOULD do this, just that we could, particularly if we did write a formatter.
Dan
>
> According to the slf4j website logback and log4j support MDCs (I am
> presuming that log4j2 does also therefore)
>
> On Tuesday, 11 December 2012, Stephen Connolly 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 th
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
Another criteria that people should pay attention to is whether the
implementation supports Mapped Diagnostic Contexts
http://logback.qos.ch/manual/mdc.html
AFAIU this may rule out JUL as a serious implementation... In other words
when we want to start using MDCs to make it easier to navigate the logs, if
the implementation we choose does not support MDCs then we would need to
choose again.
According to the slf4j website logback and log4j support MDCs (I am
presuming that log4j2 does also therefore)
On Tuesday, 11 December 2012, Stephen Connolly 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 th
>
Re: Logback in Maven Core
Posted by Jason van Zyl <ja...@tesla.io>.
Stephen,
Thanks for the complete explanation, I'm a little logging beleaguered :-)
On Dec 11, 2012, at 4:18 AM, Stephen Connolly <st...@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.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" <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.
Re: Logback in Maven Core
Posted by Ralph Goers <ra...@dslextreme.com>.
Oh - FWIW I'm running on OSX 10.7.5 with a 2.5 GHz Intel Core i7 with 16GB of memory.
Ralph
On Dec 12, 2012, at 12:27 AM, Ralph Goers wrote:
> I checked out Maven and used its build as a comparison. First, I ran the log4j 2 build and it was taking around 59 seconds. I then changed the log4j2.xml to remove the colors. I then got an average time for Log4j 2 of 54.76s and for Logback I get an average of 55.225s. I consider these differences to be meaningless.
>
> For reference, the log4j2.xml I used is attached.
>
> Ralph
>
> <log4j2.xml>
>
>
>
>
>
>
>
> On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
>
>> Well I am not going to tar and feather log4j2 based on one set of runs on
>> my machine. I would like somebody else to repeat and confirm first as there
>> could have been some background OS update or other process stealing CPU
>> while doing the 3 log4j2 runs.
>>
>> Also I do not know if I am comparing the same things. Afaik the log back
>> branch has the latest fixes in it, while the log4j2 branch is the colorized
>> one from a few weeks back and likely has not got the fixes required for the
>> issues you identified with the last 3.1.0 RC
>>
>> We need to compare like with like to make an informed decision... I am just
>> putting some numbers down as a starting point
>>
>> -Stephen
>>
>> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
>>
>>> Finally some interesting numbers, and if (heaven forbid) this decision
>>> should be based on
>>> technical grounds, this is one of the first significant pieces to come
>>> up in this discussion.
>>>
>>> Since I am quite unfamiliar with logging (I use loose coupling and
>>> tests instead ;), I took the opportunity to read
>>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
>>> real-life results don't seem to match up with the advertising blurp on
>>> the log4j site. While it hardly surprises me, I was wondering if
>>> anyone actually knows why?
>>>
>>> Kristian
>>>
>>>
>>>
>>> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com<javascript:;>
>>>> :
>>>> 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
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Mark Struberg <st...@yahoo.de>.
I only do those benchmarks on a desktop linux box with the cpu governer set to a fixed frequency.
Imo that's the only way to get reproducible numbers.
Especially when working on a notebook it also depends how much heat the notebook can dissipate. I've seen my MBP not using his full turbo when he is really hot after benchmarks (even singlethreaded).
LieGrue,
strub
----- Original Message -----
> From: Kristian Rosenvold <kr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Wednesday, December 12, 2012 9:35 AM
> Subject: Re: Logback in Maven Core
>
> Yeah, measuring performance on modern cpu's is totally borked. To get
> any real measurements one probably needs to to average of 100 non-stop
> builds or similar, to counter for all the dark magics intel do with
> temperature-based overclocking.
>
> I think I've seen somewhere that it's possible to disable all the
> cpu-voodo in the bios. But what a pain to reboot to change those
> settings ! Or dig out the old Pentium4 from the closet.
>
> Kristian
>
> 2012/12/12 Ralph Goers <ra...@dslextreme.com>:
>> I checked out Maven and used its build as a comparison. First, I ran the
> log4j 2 build and it was taking around 59 seconds. I then changed the
> log4j2.xml to remove the colors. I then got an average time for Log4j 2 of
> 54.76s and for Logback I get an average of 55.225s. I consider these
> differences to be meaningless.
>>
>> For reference, the log4j2.xml I used is attached.
>>
>> Ralph
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
>>
>>> Well I am not going to tar and feather log4j2 based on one set of runs
> on
>>> my machine. I would like somebody else to repeat and confirm first as
> there
>>> could have been some background OS update or other process stealing CPU
>>> while doing the 3 log4j2 runs.
>>>
>>> Also I do not know if I am comparing the same things. Afaik the log
> back
>>> branch has the latest fixes in it, while the log4j2 branch is the
> colorized
>>> one from a few weeks back and likely has not got the fixes required for
> the
>>> issues you identified with the last 3.1.0 RC
>>>
>>> We need to compare like with like to make an informed decision... I am
> just
>>> putting some numbers down as a starting point
>>>
>>> -Stephen
>>>
>>> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
>>>
>>>> Finally some interesting numbers, and if (heaven forbid) this
> decision
>>>> should be based on
>>>> technical grounds, this is one of the first significant pieces to
> come
>>>> up in this discussion.
>>>>
>>>> Since I am quite unfamiliar with logging (I use loose coupling and
>>>> tests instead ;), I took the opportunity to read
>>>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
>>>> real-life results don't seem to match up with the advertising
> blurp on
>>>> the log4j site. While it hardly surprises me, I was wondering if
>>>> anyone actually knows why?
>>>>
>>>> Kristian
>>>>
>>>>
>>>>
>>>> 2012/12/12 Stephen Connolly
> <stephen.alan.connolly@gmail.com<javascript:;>
>>>>> :
>>>>> 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
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
>>>>
>>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
The idea behind these binaries is to give everyone the opportunity to make
decisions with regards to the technical gates:
1. Does it pass the integration tests
2. Is it roughly equivalent in terms of performance to 3.0.4 (can be better
or up to say 5% worse)
There are additional criteria people can consider as well. These proof of
concept builds should at least allow everyone to compare like with like...
as I have made a bit of effort to ensure that the diffs between the
branches are as minimal as I can get them (i.e. just what is required to
support the logging framework, no colorised loggers)
For people who see being able to implement colorised logging:
1. Logback and Log4j2 support this natively
2. JUL could be written to support this (i.e. we need to write a custom
Formatter anyway, no reason we couldn't add the ANSI support too)
3. Log4j 1.2 doesn't support, but hey if we want to we could always write
and maintain that! (If we want to have [WARNING] as before we would have to
write a formatter anyway... once again, while we are in there!)
On 12 December 2012 11:40, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> I have built some binaries for people to play with:
>
> http://people.apache.org/~stephenc/
>
> MD5 (apache-maven-3.1.0-pre-jul.tar.gz) = dd40afbfa64ab53f614ede19385e4a48
> MD5 (apache-maven-3.1.0-pre-jul.zip) = 731fe7136e96e2027d145d993d917f20
> MD5 (apache-maven-3.1.0-pre-log4j.tar.gz) =
> 63fead6accb60ca52c8a299c39d172f5
> MD5 (apache-maven-3.1.0-pre-log4j.zip) = 64982b6395a80bb6f2d27020c9f439be
> MD5 (apache-maven-3.1.0-pre-log4j2.tar.gz) =
> cc38e6f2110d9e76f6fc9feb29c48500
> MD5 (apache-maven-3.1.0-pre-log4j2.zip) = 77eda0a4bbb6f82cfdff8e8afb408dd5
> MD5 (apache-maven-3.1.0-pre-logback.tar.gz) =
> b51215f3e1c5589772b4d65c68f28654
> MD5 (apache-maven-3.1.0-pre-logback.zip) = 6af89e67b1dca4699ef0ce57c3db6a5f
>
> They should all behave roughly similarly... though the log4j 1.2 version
> will probably output [WARN] and not [WARNING]
>
>
>
> On 12 December 2012 10:40, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> I am working on getting some branches for different options.
>>
>> I think I have the logging/slf4j-jul branch done...
>>
>> I think my logging/slf4j-log4j2 branch is correct
>>
>> I am fairly certain my logging/slf4j-logback branch is correct
>>
>> My logging/slf4j-log4j (i.e. 1.2) branch needs some tweaks
>>
>> If somebody can run the integration tests on those branches and report
>> the results here that would be great.
>>
>>
>> On 12 December 2012 08:48, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> Can we get a set of baseline git hashes for any versions of maven that
>>> we are comparing. I might see if I can pull logback out of the latest RC
>>> and put log4j2 and some other impls in its place so we can get some real
>>> apples for apples comparisons going
>>>
>>>
>>> On 12 December 2012 08:35, Kristian Rosenvold <
>>> kristian.rosenvold@gmail.com> wrote:
>>>
>>>> Yeah, measuring performance on modern cpu's is totally borked. To get
>>>> any real measurements one probably needs to to average of 100 non-stop
>>>> builds or similar, to counter for all the dark magics intel do with
>>>> temperature-based overclocking.
>>>>
>>>> I think I've seen somewhere that it's possible to disable all the
>>>> cpu-voodo in the bios. But what a pain to reboot to change those
>>>> settings ! Or dig out the old Pentium4 from the closet.
>>>>
>>>> Kristian
>>>>
>>>> 2012/12/12 Ralph Goers <ra...@dslextreme.com>:
>>>> > I checked out Maven and used its build as a comparison. First, I ran
>>>> the log4j 2 build and it was taking around 59 seconds. I then changed the
>>>> log4j2.xml to remove the colors. I then got an average time for Log4j 2 of
>>>> 54.76s and for Logback I get an average of 55.225s. I consider these
>>>> differences to be meaningless.
>>>> >
>>>> > For reference, the log4j2.xml I used is attached.
>>>> >
>>>> > Ralph
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
>>>> >
>>>> >> Well I am not going to tar and feather log4j2 based on one set of
>>>> runs on
>>>> >> my machine. I would like somebody else to repeat and confirm first
>>>> as there
>>>> >> could have been some background OS update or other process stealing
>>>> CPU
>>>> >> while doing the 3 log4j2 runs.
>>>> >>
>>>> >> Also I do not know if I am comparing the same things. Afaik the log
>>>> back
>>>> >> branch has the latest fixes in it, while the log4j2 branch is the
>>>> colorized
>>>> >> one from a few weeks back and likely has not got the fixes required
>>>> for the
>>>> >> issues you identified with the last 3.1.0 RC
>>>> >>
>>>> >> We need to compare like with like to make an informed decision... I
>>>> am just
>>>> >> putting some numbers down as a starting point
>>>> >>
>>>> >> -Stephen
>>>> >>
>>>> >> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
>>>> >>
>>>> >>> Finally some interesting numbers, and if (heaven forbid) this
>>>> decision
>>>> >>> should be based on
>>>> >>> technical grounds, this is one of the first significant pieces to
>>>> come
>>>> >>> up in this discussion.
>>>> >>>
>>>> >>> Since I am quite unfamiliar with logging (I use loose coupling and
>>>> >>> tests instead ;), I took the opportunity to read
>>>> >>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
>>>> >>> real-life results don't seem to match up with the advertising blurp
>>>> on
>>>> >>> the log4j site. While it hardly surprises me, I was wondering if
>>>> >>> anyone actually knows why?
>>>> >>>
>>>> >>> Kristian
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com
>>>> <javascript:;>
>>>> >>>> :
>>>> >>>> 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
>>>> >>>
>>>> >>>
>>>> ---------------------------------------------------------------------
>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>> >>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>>> >>>
>>>> >>>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
I have built some binaries for people to play with:
http://people.apache.org/~stephenc/
MD5 (apache-maven-3.1.0-pre-jul.tar.gz) = dd40afbfa64ab53f614ede19385e4a48
MD5 (apache-maven-3.1.0-pre-jul.zip) = 731fe7136e96e2027d145d993d917f20
MD5 (apache-maven-3.1.0-pre-log4j.tar.gz) = 63fead6accb60ca52c8a299c39d172f5
MD5 (apache-maven-3.1.0-pre-log4j.zip) = 64982b6395a80bb6f2d27020c9f439be
MD5 (apache-maven-3.1.0-pre-log4j2.tar.gz) =
cc38e6f2110d9e76f6fc9feb29c48500
MD5 (apache-maven-3.1.0-pre-log4j2.zip) = 77eda0a4bbb6f82cfdff8e8afb408dd5
MD5 (apache-maven-3.1.0-pre-logback.tar.gz) =
b51215f3e1c5589772b4d65c68f28654
MD5 (apache-maven-3.1.0-pre-logback.zip) = 6af89e67b1dca4699ef0ce57c3db6a5f
They should all behave roughly similarly... though the log4j 1.2 version
will probably output [WARN] and not [WARNING]
On 12 December 2012 10:40, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> I am working on getting some branches for different options.
>
> I think I have the logging/slf4j-jul branch done...
>
> I think my logging/slf4j-log4j2 branch is correct
>
> I am fairly certain my logging/slf4j-logback branch is correct
>
> My logging/slf4j-log4j (i.e. 1.2) branch needs some tweaks
>
> If somebody can run the integration tests on those branches and report the
> results here that would be great.
>
>
> On 12 December 2012 08:48, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Can we get a set of baseline git hashes for any versions of maven that we
>> are comparing. I might see if I can pull logback out of the latest RC and
>> put log4j2 and some other impls in its place so we can get some real apples
>> for apples comparisons going
>>
>>
>> On 12 December 2012 08:35, Kristian Rosenvold <
>> kristian.rosenvold@gmail.com> wrote:
>>
>>> Yeah, measuring performance on modern cpu's is totally borked. To get
>>> any real measurements one probably needs to to average of 100 non-stop
>>> builds or similar, to counter for all the dark magics intel do with
>>> temperature-based overclocking.
>>>
>>> I think I've seen somewhere that it's possible to disable all the
>>> cpu-voodo in the bios. But what a pain to reboot to change those
>>> settings ! Or dig out the old Pentium4 from the closet.
>>>
>>> Kristian
>>>
>>> 2012/12/12 Ralph Goers <ra...@dslextreme.com>:
>>> > I checked out Maven and used its build as a comparison. First, I ran
>>> the log4j 2 build and it was taking around 59 seconds. I then changed the
>>> log4j2.xml to remove the colors. I then got an average time for Log4j 2 of
>>> 54.76s and for Logback I get an average of 55.225s. I consider these
>>> differences to be meaningless.
>>> >
>>> > For reference, the log4j2.xml I used is attached.
>>> >
>>> > Ralph
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
>>> >
>>> >> Well I am not going to tar and feather log4j2 based on one set of
>>> runs on
>>> >> my machine. I would like somebody else to repeat and confirm first as
>>> there
>>> >> could have been some background OS update or other process stealing
>>> CPU
>>> >> while doing the 3 log4j2 runs.
>>> >>
>>> >> Also I do not know if I am comparing the same things. Afaik the log
>>> back
>>> >> branch has the latest fixes in it, while the log4j2 branch is the
>>> colorized
>>> >> one from a few weeks back and likely has not got the fixes required
>>> for the
>>> >> issues you identified with the last 3.1.0 RC
>>> >>
>>> >> We need to compare like with like to make an informed decision... I
>>> am just
>>> >> putting some numbers down as a starting point
>>> >>
>>> >> -Stephen
>>> >>
>>> >> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
>>> >>
>>> >>> Finally some interesting numbers, and if (heaven forbid) this
>>> decision
>>> >>> should be based on
>>> >>> technical grounds, this is one of the first significant pieces to
>>> come
>>> >>> up in this discussion.
>>> >>>
>>> >>> Since I am quite unfamiliar with logging (I use loose coupling and
>>> >>> tests instead ;), I took the opportunity to read
>>> >>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
>>> >>> real-life results don't seem to match up with the advertising blurp
>>> on
>>> >>> the log4j site. While it hardly surprises me, I was wondering if
>>> >>> anyone actually knows why?
>>> >>>
>>> >>> Kristian
>>> >>>
>>> >>>
>>> >>>
>>> >>> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com
>>> <javascript:;>
>>> >>>> :
>>> >>>> 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
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>> >>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>> >>>
>>> >>>
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
I am working on getting some branches for different options.
I think I have the logging/slf4j-jul branch done...
I think my logging/slf4j-log4j2 branch is correct
I am fairly certain my logging/slf4j-logback branch is correct
My logging/slf4j-log4j (i.e. 1.2) branch needs some tweaks
If somebody can run the integration tests on those branches and report the
results here that would be great.
On 12 December 2012 08:48, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> Can we get a set of baseline git hashes for any versions of maven that we
> are comparing. I might see if I can pull logback out of the latest RC and
> put log4j2 and some other impls in its place so we can get some real apples
> for apples comparisons going
>
>
> On 12 December 2012 08:35, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
>> Yeah, measuring performance on modern cpu's is totally borked. To get
>> any real measurements one probably needs to to average of 100 non-stop
>> builds or similar, to counter for all the dark magics intel do with
>> temperature-based overclocking.
>>
>> I think I've seen somewhere that it's possible to disable all the
>> cpu-voodo in the bios. But what a pain to reboot to change those
>> settings ! Or dig out the old Pentium4 from the closet.
>>
>> Kristian
>>
>> 2012/12/12 Ralph Goers <ra...@dslextreme.com>:
>> > I checked out Maven and used its build as a comparison. First, I ran
>> the log4j 2 build and it was taking around 59 seconds. I then changed the
>> log4j2.xml to remove the colors. I then got an average time for Log4j 2 of
>> 54.76s and for Logback I get an average of 55.225s. I consider these
>> differences to be meaningless.
>> >
>> > For reference, the log4j2.xml I used is attached.
>> >
>> > Ralph
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
>> >
>> >> Well I am not going to tar and feather log4j2 based on one set of runs
>> on
>> >> my machine. I would like somebody else to repeat and confirm first as
>> there
>> >> could have been some background OS update or other process stealing CPU
>> >> while doing the 3 log4j2 runs.
>> >>
>> >> Also I do not know if I am comparing the same things. Afaik the log
>> back
>> >> branch has the latest fixes in it, while the log4j2 branch is the
>> colorized
>> >> one from a few weeks back and likely has not got the fixes required
>> for the
>> >> issues you identified with the last 3.1.0 RC
>> >>
>> >> We need to compare like with like to make an informed decision... I am
>> just
>> >> putting some numbers down as a starting point
>> >>
>> >> -Stephen
>> >>
>> >> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
>> >>
>> >>> Finally some interesting numbers, and if (heaven forbid) this decision
>> >>> should be based on
>> >>> technical grounds, this is one of the first significant pieces to come
>> >>> up in this discussion.
>> >>>
>> >>> Since I am quite unfamiliar with logging (I use loose coupling and
>> >>> tests instead ;), I took the opportunity to read
>> >>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
>> >>> real-life results don't seem to match up with the advertising blurp on
>> >>> the log4j site. While it hardly surprises me, I was wondering if
>> >>> anyone actually knows why?
>> >>>
>> >>> Kristian
>> >>>
>> >>>
>> >>>
>> >>> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com
>> <javascript:;>
>> >>>> :
>> >>>> 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
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>> >>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>> >>>
>> >>>
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
Can we get a set of baseline git hashes for any versions of maven that we
are comparing. I might see if I can pull logback out of the latest RC and
put log4j2 and some other impls in its place so we can get some real apples
for apples comparisons going
On 12 December 2012 08:35, Kristian Rosenvold
<kr...@gmail.com>wrote:
> Yeah, measuring performance on modern cpu's is totally borked. To get
> any real measurements one probably needs to to average of 100 non-stop
> builds or similar, to counter for all the dark magics intel do with
> temperature-based overclocking.
>
> I think I've seen somewhere that it's possible to disable all the
> cpu-voodo in the bios. But what a pain to reboot to change those
> settings ! Or dig out the old Pentium4 from the closet.
>
> Kristian
>
> 2012/12/12 Ralph Goers <ra...@dslextreme.com>:
> > I checked out Maven and used its build as a comparison. First, I ran
> the log4j 2 build and it was taking around 59 seconds. I then changed the
> log4j2.xml to remove the colors. I then got an average time for Log4j 2 of
> 54.76s and for Logback I get an average of 55.225s. I consider these
> differences to be meaningless.
> >
> > For reference, the log4j2.xml I used is attached.
> >
> > Ralph
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
> >
> >> Well I am not going to tar and feather log4j2 based on one set of runs
> on
> >> my machine. I would like somebody else to repeat and confirm first as
> there
> >> could have been some background OS update or other process stealing CPU
> >> while doing the 3 log4j2 runs.
> >>
> >> Also I do not know if I am comparing the same things. Afaik the log back
> >> branch has the latest fixes in it, while the log4j2 branch is the
> colorized
> >> one from a few weeks back and likely has not got the fixes required for
> the
> >> issues you identified with the last 3.1.0 RC
> >>
> >> We need to compare like with like to make an informed decision... I am
> just
> >> putting some numbers down as a starting point
> >>
> >> -Stephen
> >>
> >> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
> >>
> >>> Finally some interesting numbers, and if (heaven forbid) this decision
> >>> should be based on
> >>> technical grounds, this is one of the first significant pieces to come
> >>> up in this discussion.
> >>>
> >>> Since I am quite unfamiliar with logging (I use loose coupling and
> >>> tests instead ;), I took the opportunity to read
> >>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
> >>> real-life results don't seem to match up with the advertising blurp on
> >>> the log4j site. While it hardly surprises me, I was wondering if
> >>> anyone actually knows why?
> >>>
> >>> Kristian
> >>>
> >>>
> >>>
> >>> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com
> <javascript:;>
> >>>> :
> >>>> 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
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> >>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >>>
> >>>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Logback in Maven Core
Posted by Kristian Rosenvold <kr...@gmail.com>.
Yeah, measuring performance on modern cpu's is totally borked. To get
any real measurements one probably needs to to average of 100 non-stop
builds or similar, to counter for all the dark magics intel do with
temperature-based overclocking.
I think I've seen somewhere that it's possible to disable all the
cpu-voodo in the bios. But what a pain to reboot to change those
settings ! Or dig out the old Pentium4 from the closet.
Kristian
2012/12/12 Ralph Goers <ra...@dslextreme.com>:
> I checked out Maven and used its build as a comparison. First, I ran the log4j 2 build and it was taking around 59 seconds. I then changed the log4j2.xml to remove the colors. I then got an average time for Log4j 2 of 54.76s and for Logback I get an average of 55.225s. I consider these differences to be meaningless.
>
> For reference, the log4j2.xml I used is attached.
>
> Ralph
>
>
>
>
>
>
>
>
>
>
> On Dec 11, 2012, at 11:19 PM, Stephen Connolly wrote:
>
>> Well I am not going to tar and feather log4j2 based on one set of runs on
>> my machine. I would like somebody else to repeat and confirm first as there
>> could have been some background OS update or other process stealing CPU
>> while doing the 3 log4j2 runs.
>>
>> Also I do not know if I am comparing the same things. Afaik the log back
>> branch has the latest fixes in it, while the log4j2 branch is the colorized
>> one from a few weeks back and likely has not got the fixes required for the
>> issues you identified with the last 3.1.0 RC
>>
>> We need to compare like with like to make an informed decision... I am just
>> putting some numbers down as a starting point
>>
>> -Stephen
>>
>> On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
>>
>>> Finally some interesting numbers, and if (heaven forbid) this decision
>>> should be based on
>>> technical grounds, this is one of the first significant pieces to come
>>> up in this discussion.
>>>
>>> Since I am quite unfamiliar with logging (I use loose coupling and
>>> tests instead ;), I took the opportunity to read
>>> http://logging.apache.org/log4j/2.x/performance.html Somehow the
>>> real-life results don't seem to match up with the advertising blurp on
>>> the log4j site. While it hardly surprises me, I was wondering if
>>> anyone actually knows why?
>>>
>>> Kristian
>>>
>>>
>>>
>>> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com<javascript:;>
>>>> :
>>>> 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
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>>>
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Ralph Goers <ra...@dslextreme.com>.
I checked out Maven and used its build as a comparison. First, I ran the log4j 2 build and it was taking around 59 seconds. I then changed the log4j2.xml to remove the colors. I then got an average time for Log4j 2 of 54.76s and for Logback I get an average of 55.225s. I consider these differences to be meaningless.
For reference, the log4j2.xml I used is attached.
Ralph
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
Well I am not going to tar and feather log4j2 based on one set of runs on
my machine. I would like somebody else to repeat and confirm first as there
could have been some background OS update or other process stealing CPU
while doing the 3 log4j2 runs.
Also I do not know if I am comparing the same things. Afaik the log back
branch has the latest fixes in it, while the log4j2 branch is the colorized
one from a few weeks back and likely has not got the fixes required for the
issues you identified with the last 3.1.0 RC
We need to compare like with like to make an informed decision... I am just
putting some numbers down as a starting point
-Stephen
On Wednesday, 12 December 2012, Kristian Rosenvold wrote:
> Finally some interesting numbers, and if (heaven forbid) this decision
> should be based on
> technical grounds, this is one of the first significant pieces to come
> up in this discussion.
>
> Since I am quite unfamiliar with logging (I use loose coupling and
> tests instead ;), I took the opportunity to read
> http://logging.apache.org/log4j/2.x/performance.html Somehow the
> real-life results don't seem to match up with the advertising blurp on
> the log4j site. While it hardly surprises me, I was wondering if
> anyone actually knows why?
>
> Kristian
>
>
>
> 2012/12/12 Stephen Connolly <stephen.alan.connolly@gmail.com<javascript:;>
> >:
> > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
Re: Logback in Maven Core
Posted by Daniel Kulp <dk...@apache.org>.
I ran the CXF build like:
mvn -Pfastinstall -T8 -o
using the latest on the two branches as of 11pm last night:
3.0.4: 1:16
log4j2: 1:12
logback: 1:19
Ran each 3 times and results were fairly consistent. Thus, for me using parallel builds, log4j2 is the fastest, but the difference is almost irrelevant.
I'll repeat the tests later without the -T8, but this may show that multi-threaded logging is faster with log4j2.
Dan
On Dec 12, 2012, at 1:48 AM, Kristian Rosenvold <kr...@gmail.com> wrote:
> Finally some interesting numbers, and if (heaven forbid) this decision
> should be based on
> technical grounds, this is one of the first significant pieces to come
> up in this discussion.
>
> Since I am quite unfamiliar with logging (I use loose coupling and
> tests instead ;), I took the opportunity to read
> http://logging.apache.org/log4j/2.x/performance.html Somehow the
> real-life results don't seem to match up with the advertising blurp on
> the log4j site. While it hardly surprises me, I was wondering if
> anyone actually knows why?
>
> Kristian
>
>
>
> 2012/12/12 Stephen Connolly <st...@gmail.com>:
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Kristian Rosenvold <kr...@gmail.com>.
Finally some interesting numbers, and if (heaven forbid) this decision
should be based on
technical grounds, this is one of the first significant pieces to come
up in this discussion.
Since I am quite unfamiliar with logging (I use loose coupling and
tests instead ;), I took the opportunity to read
http://logging.apache.org/log4j/2.x/performance.html Somehow the
real-life results don't seem to match up with the advertising blurp on
the log4j site. While it hardly surprises me, I was wondering if
anyone actually knows why?
Kristian
2012/12/12 Stephen Connolly <st...@gmail.com>:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
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 <st...@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.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" <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.
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
Re: Logback in Maven Core
Posted by Jesse McConnell <je...@gmail.com>.
+1 for logback!
--
jesse mcconnell
jesse.mcconnell@gmail.com
On Tue, Dec 11, 2012 at 3:18 AM, Stephen Connolly <st...@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.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" <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.
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@apache.org>.
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" <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.
> >
> >
> >
> >
> >
> >
>
Re: Logback in Maven Core
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Think for everyday users (i'm part of them) it doesnt make so much
difference so since the logs are the same and the impl is easier logback
sounds good.
Le 11 déc. 2012 08:14, "Ansgar Konermann" <an...@googlemail.com>
a écrit :
> 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.
> >
> >
> >
> >
> >
> >
>
Re: Logback in Maven Core
Posted by Ansgar Konermann <an...@googlemail.com>.
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.
>
>
>
>
>
>
Re: Logback in Maven Core
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 11 décembre 2012 20:27:15 Jason van Zyl a écrit :
> Would be easy enough to create a template method in MavenCli which in which
> subclasses can override to do any setup of the underlying logging system.
> Much like the createModelProcessor() method in the MavenCli currently.
yes
IMHO, this could give an idea of what new API would be useful in slf4j-api in
future versions: I don't expect much methods
Regards,
Hervé
> On Dec 11, 2012, at 7:39 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> > same for me
> >
> > with one precision: IMHO, the few places where we'll have to write
> > implementation-specific code need to be placed in a separate class to ease
> > changing implementation
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 11 décembre 2012 16:19:12 Daniel Kulp a écrit :
> >> My thoughts:
> >> 99.5% (or more) of the maven users will not care one way or another what
> >> logging impl we use. They won't configure anything beyond -X. They
> >> won't
> >> try changing loggers. They won't muck with the configs. Etc.. They
> >> just run "mvn" and expect it to work.
> >>
> >> For the remaining <0.5%, no matter what we do, we will need to document
> >> things clearly about how to configure things. For these folks, they are
> >> generally "experts" and thus a couple extra steps to replace a logging
> >> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT
> >> this all clearly or provide a nice maven plugin or something to do it for
> >> them)
> >>
> >>
> >> My preference, in order:
> >>
> >> slf4j-jdk14
> >> slf4j-simple
> >> log4j2
> >> slf4j-log4j
> >>
> >> and then a big gap to logback.
> >>
> >> The first two are there as they would provide the least amount of "extra
> >> dependencies", complexity, etc… That said, we know slf4j-simple has
> >> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
> >> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
> >> If the entire argument is around wanting something "battle tested", go
> >> for
> >> slf4j-log4j. It's certainly used by more projects than logback and more
> >> people would already know it's configuration options. Personally, I
> >> find
> >> the "number of projects" argument annoying and mostly irrelevant. (and
> >> at
> >> least 2 of the "Apache 8" projects that are on the logback homepage don't
> >> use logback, they now use slf4j-log4j)
> >>
> >> Thus, it comes down to two major things for me:
> >>
> >> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
> >> vote
> >> -1 for logback if/when presented to the PMC for approval. There are
> >> very
> >> good options that would work just as well for our needs that are not EPL.
> >>
> >> 2) Community - Ceki is great, no doubt about it, but at the end of the
> >> day,
> >> logback is pretty much a one man show. Apache is more about "community"
> >> and "community over code" and all that. I strongly prefer something
> >> that
> >> has a community behind it, or, at the very least, is open to developing a
> >> community behind it. Major bonus points if that community already
> >> contains Maven PMC members/committers on it. If *we* run into issues,
> >> I
> >> strongly prefer that *we* can get those issues fixed.
> >>
> >> If two options are functionally and technically equivalent (within
> >> reasonable limits), then I'll take the community driven, permissive
> >> licensed version.
> >>
> >> That's my $0.02 worth.
> >>
> >> Dan
> >>
> >> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
> >>> 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.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can fix
> bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Jason van Zyl <ja...@tesla.io>.
Would be easy enough to create a template method in MavenCli which in which subclasses can override to do any setup of the underlying logging system. Much like the createModelProcessor() method in the MavenCli currently.
On Dec 11, 2012, at 7:39 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> same for me
>
> with one precision: IMHO, the few places where we'll have to write
> implementation-specific code need to be placed in a separate class to ease
> changing implementation
>
> Regards,
>
> Hervé
>
> Le mardi 11 décembre 2012 16:19:12 Daniel Kulp a écrit :
>> My thoughts:
>> 99.5% (or more) of the maven users will not care one way or another what
>> logging impl we use. They won't configure anything beyond -X. They won't
>> try changing loggers. They won't muck with the configs. Etc.. They
>> just run "mvn" and expect it to work.
>>
>> For the remaining <0.5%, no matter what we do, we will need to document
>> things clearly about how to configure things. For these folks, they are
>> generally "experts" and thus a couple extra steps to replace a logging
>> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT
>> this all clearly or provide a nice maven plugin or something to do it for
>> them)
>>
>>
>> My preference, in order:
>>
>> slf4j-jdk14
>> slf4j-simple
>> log4j2
>> slf4j-log4j
>>
>> and then a big gap to logback.
>>
>> The first two are there as they would provide the least amount of "extra
>> dependencies", complexity, etc… That said, we know slf4j-simple has
>> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
>> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
>> If the entire argument is around wanting something "battle tested", go for
>> slf4j-log4j. It's certainly used by more projects than logback and more
>> people would already know it's configuration options. Personally, I find
>> the "number of projects" argument annoying and mostly irrelevant. (and at
>> least 2 of the "Apache 8" projects that are on the logback homepage don't
>> use logback, they now use slf4j-log4j)
>>
>> Thus, it comes down to two major things for me:
>>
>> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote
>> -1 for logback if/when presented to the PMC for approval. There are very
>> good options that would work just as well for our needs that are not EPL.
>>
>> 2) Community - Ceki is great, no doubt about it, but at the end of the day,
>> logback is pretty much a one man show. Apache is more about "community"
>> and "community over code" and all that. I strongly prefer something that
>> has a community behind it, or, at the very least, is open to developing a
>> community behind it. Major bonus points if that community already
>> contains Maven PMC members/committers on it. If *we* run into issues, I
>> strongly prefer that *we* can get those issues fixed.
>>
>> If two options are functionally and technically equivalent (within
>> reasonable limits), then I'll take the community driven, permissive
>> licensed version.
>>
>> That's my $0.02 worth.
>>
>> Dan
>>
>> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
>>> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
Re: Logback in Maven Core
Posted by Hervé BOUTEMY <he...@free.fr>.
same for me
with one precision: IMHO, the few places where we'll have to write
implementation-specific code need to be placed in a separate class to ease
changing implementation
Regards,
Hervé
Le mardi 11 décembre 2012 16:19:12 Daniel Kulp a écrit :
> My thoughts:
> 99.5% (or more) of the maven users will not care one way or another what
> logging impl we use. They won't configure anything beyond -X. They won't
> try changing loggers. They won't muck with the configs. Etc.. They
> just run "mvn" and expect it to work.
>
> For the remaining <0.5%, no matter what we do, we will need to document
> things clearly about how to configure things. For these folks, they are
> generally "experts" and thus a couple extra steps to replace a logging
> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT
> this all clearly or provide a nice maven plugin or something to do it for
> them)
>
>
> My preference, in order:
>
> slf4j-jdk14
> slf4j-simple
> log4j2
> slf4j-log4j
>
> and then a big gap to logback.
>
> The first two are there as they would provide the least amount of "extra
> dependencies", complexity, etc… That said, we know slf4j-simple has
> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
> If the entire argument is around wanting something "battle tested", go for
> slf4j-log4j. It's certainly used by more projects than logback and more
> people would already know it's configuration options. Personally, I find
> the "number of projects" argument annoying and mostly irrelevant. (and at
> least 2 of the "Apache 8" projects that are on the logback homepage don't
> use logback, they now use slf4j-log4j)
>
> Thus, it comes down to two major things for me:
>
> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote
> -1 for logback if/when presented to the PMC for approval. There are very
> good options that would work just as well for our needs that are not EPL.
>
> 2) Community - Ceki is great, no doubt about it, but at the end of the day,
> logback is pretty much a one man show. Apache is more about "community"
> and "community over code" and all that. I strongly prefer something that
> has a community behind it, or, at the very least, is open to developing a
> community behind it. Major bonus points if that community already
> contains Maven PMC members/committers on it. If *we* run into issues, I
> strongly prefer that *we* can get those issues fixed.
>
> If two options are functionally and technically equivalent (within
> reasonable limits), then I'll take the community driven, permissive
> licensed version.
>
> That's my $0.02 worth.
>
> Dan
>
> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
> > 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
On 11 December 2012 21:39, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
>
>
> On Tuesday, 11 December 2012, Daniel Kulp wrote:
>
>>
>>
>> My thoughts:
>> 99.5% (or more) of the maven users will not care one way or another what
>> logging impl we use. They won't configure anything beyond -X. They won't
>> try changing loggers. They won't muck with the configs. Etc.. They
>> just run "mvn" and expect it to work.
>>
>> For the remaining <0.5%, no matter what we do, we will need to document
>> things clearly about how to configure things. For these folks, they are
>> generally "experts" and thus a couple extra steps to replace a logging
>> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT
>> this all clearly or provide a nice maven plugin or something to do it for
>> them)
>>
>>
>> My preference, in order:
>>
>> slf4j-jdk14
>> slf4j-simple
>> log4j2
>> slf4j-log4j
>>
>> and then a big gap to logback.
>>
>> The first two are there as they would provide the least amount of "extra
>> dependencies", complexity, etc… That said, we know slf4j-simple has
>> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
>> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
>> If the entire argument is around wanting something "battle tested", go for
>> slf4j-log4j. It's certainly used by more projects than logback and more
>> people would already know it's configuration options. Personally, I find
>> the "number of projects" argument annoying and mostly irrelevant. (and at
>> least 2 of the "Apache 8" projects that are on the logback homepage don't
>> use logback, they now use slf4j-log4j)
>>
>> Thus, it comes down to two major things for me:
>>
>> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
>> vote -1 for logback if/when presented to the PMC for approval.
>
> There are very good options that would work just as well for our needs
>> that are not EPL.
>
>
> My points are:
>
> 1. that we should make sure the selected implementation passes the
> technical gate *first*
>
> 2. That committers should not worry about the outcome of a PMC vote when
> making their recommendation on implementation. If the PMC chooses to say no
> to a specific dependency on the basis of its license *then* the community
> will presumably have a second option that passes the technical gate and can
> fall back to that... But the very first question that committers should
> consider is the technical basis.
>
To put point 2 a second way. The PMC could decide to change the rules and
require a majority of the PMC to approve *any* change to a dependency in
core. Or it could change the rules and allow Cat B licenses without a vote
of the majority of the PMC.
Committers should not make their recommendation based on
theoretical possibilities of what the PMC may or may not do.
If committers have personal criteria about the choice of licenses on
components, then that is fine and perfectly acceptable. Just do not bias
your choice based on hypothetical future actions of the PMC.
>
> I don't care what criteria people use as long as technical is #1.
>
>
>>
>> 2) Community - Ceki is great, no doubt about it, but at the end of the
>> day, logback is pretty much a one man show. Apache is more about
>> "community" and "community over code" and all that. I strongly prefer
>> something that has a community behind it, or, at the very least, is open to
>> developing a community behind it. Major bonus points if that community
>> already contains Maven PMC members/committers on it. If *we* run into
>> issues, I strongly prefer that *we* can get those issues fixed.
>>
>> If two options are functionally and technically equivalent (within
>> reasonable limits), then I'll take the community driven, permissive
>> licensed version.
>
>
> Thank you for stating your criteria
>
> I wish everyone else could follow your example
>
>
>>
>> That's my $0.02 worth.
>>
>> Dan
>>
>>
>>
>>
>>
>>
>>
>>
>> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
>>
>> > 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.
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: Logback in Maven Core
Posted by Brian Fox <br...@infinity.nu>.
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies <bi...@gmail.com>wrote:
>
> If we ever got that far, I would argue pretty strenuously against a
> PMC-level rejection of something just based on being EPL. A class-B
> license is a perfectly legitimate dependency.
As would I. If we were talking about binding our apis against a class-B, I
might feel different, but we aren't. We're talking about using SLF4J as the
api and logback as the implementation. If someone needs to come along and
use a different logger impl, is it that big of a deal?
I'd like to hear from someone who does Linux repackaging of Maven on this
topic...
Re: Logback in Maven Core
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies <bi...@gmail.com>wrote:
> I want to gently argue with a part of Dan Kulp's position. The PMC
> established the class B dependency rule in response to a particular
> conflict within this community. From my point of view, whether or not
> that conflict is entirely in our past, logback is not an example of
> the problem that the rule was intended to address. It is not a case of
> forking Maven code out and then licensing the derived work as EPL.
>
> If we ever got that far, I would argue pretty strenuously against a
> PMC-level rejection of something just based on being EPL. A class-B
> license is a perfectly legitimate dependency.
>
> Dan's points about preferring to use something with a community behind
> it do not disturb me. However, seriously, does anyone believe that any
> of these candidates are going to manifest some horrible problem that
> we need to get fixed?
>
> To me, the sophistication depends on our vision for the widespread use
> of the slf4j API in plugins. I hate the current -X behavior, with its
> horrible undifferentiated spew, with the power of 1000 suns.
LOL
> If
> picking logback offers a clean engineering pathway to helping users
> see only messages that will help them (which, of course, depends on
> plugins enabling the slf4j API and using it), then I'm all for
> logback. If there's all much of a muchness in this regard, then we
> might as well use the JDK.
>
Check. Any logging framework with a fair sprinkling of different logger
objects would do the job. They key is for the application to slice and dice
it's use of the logging framework with loggers that make sense for both
users that need to debug builds and developers that need to debug plugins.
Gary
>
>
> On Tue, Dec 11, 2012 at 4:54 PM, Stephen Connolly
> <st...@gmail.com> wrote:
> > On 11 December 2012 21:49, Olivier Lamy <ol...@apache.org> wrote:
> >
> >> 2012/12/11 Stephen Connolly <st...@gmail.com>:
> >> > On Tuesday, 11 December 2012, Daniel Kulp wrote:
> >> >
> >> >>
> >> >>
> >> >> My thoughts:
> >> >> 99.5% (or more) of the maven users will not care one way or another
> what
> >> >> logging impl we use. They won't configure anything beyond -X. They
> >> won't
> >> >> try changing loggers. They won't muck with the configs. Etc..
> They
> >> >> just run "mvn" and expect it to work.
> >> >>
> >> >> For the remaining <0.5%, no matter what we do, we will need to
> document
> >> >> things clearly about how to configure things. For these folks, they
> >> are
> >> >> generally "experts" and thus a couple extra steps to replace a
> logging
> >> >> framework, edit configs, etc… is not a big deal at all. (again,
> >> DOCUMENT
> >> >> this all clearly or provide a nice maven plugin or something to do it
> >> for
> >> >> them)
> >> >>
> >> >>
> >> >> My preference, in order:
> >> >>
> >> >> slf4j-jdk14
> >> >> slf4j-simple
> >> >> log4j2
> >> >> slf4j-log4j
> >> >>
> >> >> and then a big gap to logback.
> >> >>
> >> >> The first two are there as they would provide the least amount of
> "extra
> >> >> dependencies", complexity, etc… That said, we know slf4j-simple has
> >> >> issues. Not sure if anyone has even tried slf4j-jdk14. For our
> CLI
> >> >> case, I don't see any advantage of logback over log4j2 or
> slf4j-log4j.
> >> >> If the entire argument is around wanting something "battle tested",
> go
> >> for
> >> >> slf4j-log4j. It's certainly used by more projects than logback and
> >> more
> >> >> people would already know it's configuration options. Personally, I
> >> find
> >> >> the "number of projects" argument annoying and mostly irrelevant.
> (and
> >> at
> >> >> least 2 of the "Apache 8" projects that are on the logback homepage
> >> don't
> >> >> use logback, they now use slf4j-log4j)
> >> >>
> >> >> Thus, it comes down to two major things for me:
> >> >>
> >> >> 1) License issues - (sorry Stephen, this IS an issue) I fully plan
> to
> >> >> vote -1 for logback if/when presented to the PMC for approval.
> There
> >> are
> >> >> very good options that would work just as well for our needs that are
> >> not
> >> >> EPL.
> >> >
> >> >
> >> > My points are:
> >> >
> >> > 1. that we should make sure the selected implementation passes the
> >> > technical gate *first*
> >> >
> >>
> >> Any technical definition of this gate ?
> >>
> >
> > All integration tests pass and no significant performance regression (I
> > would say >5% is significant but I agree we do not have a strict measure
> of
> > that).
> >
> > My first mail on this thread is awaiting confirmation from you that
> log4j2
> > meets the above.
> >
> >
> >>
> >> > 2. That committers should not worry about the outcome of a PMC vote
> when
> >> > making their recommendation on implementation. If the PMC chooses to
> say
> >> no
> >> > to a specific dependency on the basis of its license *then* the
> community
> >> > will presumably have a second option that passes the technical gate
> and
> >> can
> >> > fall back to that... But the very first question that committers
> should
> >> > consider is the technical basis.
> >> >
> >> > I don't care what criteria people use as long as technical is #1.
> >> >
> >> >
> >> >>
> >> >> 2) Community - Ceki is great, no doubt about it, but at the end of
> the
> >> >> day, logback is pretty much a one man show. Apache is more about
> >> >> "community" and "community over code" and all that. I strongly
> prefer
> >> >> something that has a community behind it, or, at the very least, is
> >> open to
> >> >> developing a community behind it. Major bonus points if that
> community
> >> >> already contains Maven PMC members/committers on it. If *we* run
> into
> >> >> issues, I strongly prefer that *we* can get those issues fixed.
> >> >>
> >> >> If two options are functionally and technically equivalent (within
> >> >> reasonable limits), then I'll take the community driven, permissive
> >> >> licensed version.
> >> >
> >>
> >> I have already explained my opinion in other threads. So nothing more
> >> to add (maybe I'm lazy for copy/paste :-))
> >> I tend to follow Dan explanations as it's similar to mine.
> >> So -1 for logback.
> >>
> >> >
> >> > Thank you for stating your criteria
> >> >
> >> > I wish everyone else could follow your example
> >> >
> >> >
> >> >>
> >> >> That's my $0.02 worth.
> >> >>
> >> >> Dan
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io
> <javascript:;>>
> >> >> wrote:
> >> >>
> >> >> > 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.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> Daniel Kulp
> >> >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> >> >> Talend Community Coder - http://coders.talend.com
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Logback in Maven Core
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Dec 11, 2012 at 5:32 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> On Dec 11, 2012, at 5:07 PM, Benson Margulies <bi...@gmail.com> wrote:
>
>> I want to gently argue with a part of Dan Kulp's position. The PMC
>> established the class B dependency rule in response to a particular
>> conflict within this community. From my point of view, whether or not
>> that conflict is entirely in our past, logback is not an example of
>> the problem that the rule was intended to address. It is not a case of
>> forking Maven code out and then licensing the derived work as EPL.
>>
>> If we ever got that far, I would argue pretty strenuously against a
>> PMC-level rejection of something just based on being EPL. A class-B
>> license is a perfectly legitimate dependency.
>>
>> Dan's points about preferring to use something with a community behind
>> it do not disturb me. However, seriously, does anyone believe that any
>> of these candidates are going to manifest some horrible problem that
>> we need to get fixed?
>
> Umm.. how about adding things, like color?
I don't know about that. I'll think about it.
>
>> To me, the sophistication depends on our vision for the widespread use
>> of the slf4j API in plugins. I hate the current -X behavior, with its
>> horrible undifferentiated spew, with the power of 1000 suns. If
>> picking logback offers a clean engineering pathway to helping users
>> see only messages that will help them (which, of course, depends on
>> plugins enabling the slf4j API and using it), then I'm all for
>> logback. If there's all much of a muchness in this regard, then we
>> might as well use the JDK.
>
> I completely agree with this. The -X behavior sucks and if logback can provide something better, that's great. However, if log4j can ALSO provide something that is equivalent to what logback could provide, then I would go with log4j.
>
> Basically, if given 2 essentially equivalent choices, I'd go with the community supported, permissively licensed option. That does require, however, 2 essentially equivalent choices. From what I see for our specific CLI use case, the two options are very close.
>
>
> Dan
>
>
>
>>
>>
>> On Tue, Dec 11, 2012 at 4:54 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>> On 11 December 2012 21:49, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>> 2012/12/11 Stephen Connolly <st...@gmail.com>:
>>>>> On Tuesday, 11 December 2012, Daniel Kulp wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> My thoughts:
>>>>>> 99.5% (or more) of the maven users will not care one way or another what
>>>>>> logging impl we use. They won't configure anything beyond -X. They
>>>> won't
>>>>>> try changing loggers. They won't muck with the configs. Etc.. They
>>>>>> just run "mvn" and expect it to work.
>>>>>>
>>>>>> For the remaining <0.5%, no matter what we do, we will need to document
>>>>>> things clearly about how to configure things. For these folks, they
>>>> are
>>>>>> generally "experts" and thus a couple extra steps to replace a logging
>>>>>> framework, edit configs, etc… is not a big deal at all. (again,
>>>> DOCUMENT
>>>>>> this all clearly or provide a nice maven plugin or something to do it
>>>> for
>>>>>> them)
>>>>>>
>>>>>>
>>>>>> My preference, in order:
>>>>>>
>>>>>> slf4j-jdk14
>>>>>> slf4j-simple
>>>>>> log4j2
>>>>>> slf4j-log4j
>>>>>>
>>>>>> and then a big gap to logback.
>>>>>>
>>>>>> The first two are there as they would provide the least amount of "extra
>>>>>> dependencies", complexity, etc… That said, we know slf4j-simple has
>>>>>> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
>>>>>> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
>>>>>> If the entire argument is around wanting something "battle tested", go
>>>> for
>>>>>> slf4j-log4j. It's certainly used by more projects than logback and
>>>> more
>>>>>> people would already know it's configuration options. Personally, I
>>>> find
>>>>>> the "number of projects" argument annoying and mostly irrelevant. (and
>>>> at
>>>>>> least 2 of the "Apache 8" projects that are on the logback homepage
>>>> don't
>>>>>> use logback, they now use slf4j-log4j)
>>>>>>
>>>>>> Thus, it comes down to two major things for me:
>>>>>>
>>>>>> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
>>>>>> vote -1 for logback if/when presented to the PMC for approval. There
>>>> are
>>>>>> very good options that would work just as well for our needs that are
>>>> not
>>>>>> EPL.
>>>>>
>>>>>
>>>>> My points are:
>>>>>
>>>>> 1. that we should make sure the selected implementation passes the
>>>>> technical gate *first*
>>>>>
>>>>
>>>> Any technical definition of this gate ?
>>>>
>>>
>>> All integration tests pass and no significant performance regression (I
>>> would say >5% is significant but I agree we do not have a strict measure of
>>> that).
>>>
>>> My first mail on this thread is awaiting confirmation from you that log4j2
>>> meets the above.
>>>
>>>
>>>>
>>>>> 2. That committers should not worry about the outcome of a PMC vote when
>>>>> making their recommendation on implementation. If the PMC chooses to say
>>>> no
>>>>> to a specific dependency on the basis of its license *then* the community
>>>>> will presumably have a second option that passes the technical gate and
>>>> can
>>>>> fall back to that... But the very first question that committers should
>>>>> consider is the technical basis.
>>>>>
>>>>> I don't care what criteria people use as long as technical is #1.
>>>>>
>>>>>
>>>>>>
>>>>>> 2) Community - Ceki is great, no doubt about it, but at the end of the
>>>>>> day, logback is pretty much a one man show. Apache is more about
>>>>>> "community" and "community over code" and all that. I strongly prefer
>>>>>> something that has a community behind it, or, at the very least, is
>>>> open to
>>>>>> developing a community behind it. Major bonus points if that community
>>>>>> already contains Maven PMC members/committers on it. If *we* run into
>>>>>> issues, I strongly prefer that *we* can get those issues fixed.
>>>>>>
>>>>>> If two options are functionally and technically equivalent (within
>>>>>> reasonable limits), then I'll take the community driven, permissive
>>>>>> licensed version.
>>>>>
>>>>
>>>> I have already explained my opinion in other threads. So nothing more
>>>> to add (maybe I'm lazy for copy/paste :-))
>>>> I tend to follow Dan explanations as it's similar to mine.
>>>> So -1 for logback.
>>>>
>>>>>
>>>>> Thank you for stating your criteria
>>>>>
>>>>> I wish everyone else could follow your example
>>>>>
>>>>>
>>>>>>
>>>>>> That's my $0.02 worth.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io<javascript:;>>
>>>>>> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Daniel Kulp <dk...@apache.org>.
On Dec 11, 2012, at 5:07 PM, Benson Margulies <bi...@gmail.com> wrote:
> I want to gently argue with a part of Dan Kulp's position. The PMC
> established the class B dependency rule in response to a particular
> conflict within this community. From my point of view, whether or not
> that conflict is entirely in our past, logback is not an example of
> the problem that the rule was intended to address. It is not a case of
> forking Maven code out and then licensing the derived work as EPL.
>
> If we ever got that far, I would argue pretty strenuously against a
> PMC-level rejection of something just based on being EPL. A class-B
> license is a perfectly legitimate dependency.
>
> Dan's points about preferring to use something with a community behind
> it do not disturb me. However, seriously, does anyone believe that any
> of these candidates are going to manifest some horrible problem that
> we need to get fixed?
Umm.. how about adding things, like color?
> To me, the sophistication depends on our vision for the widespread use
> of the slf4j API in plugins. I hate the current -X behavior, with its
> horrible undifferentiated spew, with the power of 1000 suns. If
> picking logback offers a clean engineering pathway to helping users
> see only messages that will help them (which, of course, depends on
> plugins enabling the slf4j API and using it), then I'm all for
> logback. If there's all much of a muchness in this regard, then we
> might as well use the JDK.
I completely agree with this. The -X behavior sucks and if logback can provide something better, that's great. However, if log4j can ALSO provide something that is equivalent to what logback could provide, then I would go with log4j.
Basically, if given 2 essentially equivalent choices, I'd go with the community supported, permissively licensed option. That does require, however, 2 essentially equivalent choices. From what I see for our specific CLI use case, the two options are very close.
Dan
>
>
> On Tue, Dec 11, 2012 at 4:54 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 11 December 2012 21:49, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> 2012/12/11 Stephen Connolly <st...@gmail.com>:
>>>> On Tuesday, 11 December 2012, Daniel Kulp wrote:
>>>>
>>>>>
>>>>>
>>>>> My thoughts:
>>>>> 99.5% (or more) of the maven users will not care one way or another what
>>>>> logging impl we use. They won't configure anything beyond -X. They
>>> won't
>>>>> try changing loggers. They won't muck with the configs. Etc.. They
>>>>> just run "mvn" and expect it to work.
>>>>>
>>>>> For the remaining <0.5%, no matter what we do, we will need to document
>>>>> things clearly about how to configure things. For these folks, they
>>> are
>>>>> generally "experts" and thus a couple extra steps to replace a logging
>>>>> framework, edit configs, etc… is not a big deal at all. (again,
>>> DOCUMENT
>>>>> this all clearly or provide a nice maven plugin or something to do it
>>> for
>>>>> them)
>>>>>
>>>>>
>>>>> My preference, in order:
>>>>>
>>>>> slf4j-jdk14
>>>>> slf4j-simple
>>>>> log4j2
>>>>> slf4j-log4j
>>>>>
>>>>> and then a big gap to logback.
>>>>>
>>>>> The first two are there as they would provide the least amount of "extra
>>>>> dependencies", complexity, etc… That said, we know slf4j-simple has
>>>>> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
>>>>> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
>>>>> If the entire argument is around wanting something "battle tested", go
>>> for
>>>>> slf4j-log4j. It's certainly used by more projects than logback and
>>> more
>>>>> people would already know it's configuration options. Personally, I
>>> find
>>>>> the "number of projects" argument annoying and mostly irrelevant. (and
>>> at
>>>>> least 2 of the "Apache 8" projects that are on the logback homepage
>>> don't
>>>>> use logback, they now use slf4j-log4j)
>>>>>
>>>>> Thus, it comes down to two major things for me:
>>>>>
>>>>> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
>>>>> vote -1 for logback if/when presented to the PMC for approval. There
>>> are
>>>>> very good options that would work just as well for our needs that are
>>> not
>>>>> EPL.
>>>>
>>>>
>>>> My points are:
>>>>
>>>> 1. that we should make sure the selected implementation passes the
>>>> technical gate *first*
>>>>
>>>
>>> Any technical definition of this gate ?
>>>
>>
>> All integration tests pass and no significant performance regression (I
>> would say >5% is significant but I agree we do not have a strict measure of
>> that).
>>
>> My first mail on this thread is awaiting confirmation from you that log4j2
>> meets the above.
>>
>>
>>>
>>>> 2. That committers should not worry about the outcome of a PMC vote when
>>>> making their recommendation on implementation. If the PMC chooses to say
>>> no
>>>> to a specific dependency on the basis of its license *then* the community
>>>> will presumably have a second option that passes the technical gate and
>>> can
>>>> fall back to that... But the very first question that committers should
>>>> consider is the technical basis.
>>>>
>>>> I don't care what criteria people use as long as technical is #1.
>>>>
>>>>
>>>>>
>>>>> 2) Community - Ceki is great, no doubt about it, but at the end of the
>>>>> day, logback is pretty much a one man show. Apache is more about
>>>>> "community" and "community over code" and all that. I strongly prefer
>>>>> something that has a community behind it, or, at the very least, is
>>> open to
>>>>> developing a community behind it. Major bonus points if that community
>>>>> already contains Maven PMC members/committers on it. If *we* run into
>>>>> issues, I strongly prefer that *we* can get those issues fixed.
>>>>>
>>>>> If two options are functionally and technically equivalent (within
>>>>> reasonable limits), then I'll take the community driven, permissive
>>>>> licensed version.
>>>>
>>>
>>> I have already explained my opinion in other threads. So nothing more
>>> to add (maybe I'm lazy for copy/paste :-))
>>> I tend to follow Dan explanations as it's similar to mine.
>>> So -1 for logback.
>>>
>>>>
>>>> Thank you for stating your criteria
>>>>
>>>> I wish everyone else could follow your example
>>>>
>>>>
>>>>>
>>>>> That's my $0.02 worth.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io<javascript:;>>
>>>>> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel Kulp
>>>>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Benson Margulies <bi...@gmail.com>.
I want to gently argue with a part of Dan Kulp's position. The PMC
established the class B dependency rule in response to a particular
conflict within this community. From my point of view, whether or not
that conflict is entirely in our past, logback is not an example of
the problem that the rule was intended to address. It is not a case of
forking Maven code out and then licensing the derived work as EPL.
If we ever got that far, I would argue pretty strenuously against a
PMC-level rejection of something just based on being EPL. A class-B
license is a perfectly legitimate dependency.
Dan's points about preferring to use something with a community behind
it do not disturb me. However, seriously, does anyone believe that any
of these candidates are going to manifest some horrible problem that
we need to get fixed?
To me, the sophistication depends on our vision for the widespread use
of the slf4j API in plugins. I hate the current -X behavior, with its
horrible undifferentiated spew, with the power of 1000 suns. If
picking logback offers a clean engineering pathway to helping users
see only messages that will help them (which, of course, depends on
plugins enabling the slf4j API and using it), then I'm all for
logback. If there's all much of a muchness in this regard, then we
might as well use the JDK.
On Tue, Dec 11, 2012 at 4:54 PM, Stephen Connolly
<st...@gmail.com> wrote:
> On 11 December 2012 21:49, Olivier Lamy <ol...@apache.org> wrote:
>
>> 2012/12/11 Stephen Connolly <st...@gmail.com>:
>> > On Tuesday, 11 December 2012, Daniel Kulp wrote:
>> >
>> >>
>> >>
>> >> My thoughts:
>> >> 99.5% (or more) of the maven users will not care one way or another what
>> >> logging impl we use. They won't configure anything beyond -X. They
>> won't
>> >> try changing loggers. They won't muck with the configs. Etc.. They
>> >> just run "mvn" and expect it to work.
>> >>
>> >> For the remaining <0.5%, no matter what we do, we will need to document
>> >> things clearly about how to configure things. For these folks, they
>> are
>> >> generally "experts" and thus a couple extra steps to replace a logging
>> >> framework, edit configs, etc… is not a big deal at all. (again,
>> DOCUMENT
>> >> this all clearly or provide a nice maven plugin or something to do it
>> for
>> >> them)
>> >>
>> >>
>> >> My preference, in order:
>> >>
>> >> slf4j-jdk14
>> >> slf4j-simple
>> >> log4j2
>> >> slf4j-log4j
>> >>
>> >> and then a big gap to logback.
>> >>
>> >> The first two are there as they would provide the least amount of "extra
>> >> dependencies", complexity, etc… That said, we know slf4j-simple has
>> >> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
>> >> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
>> >> If the entire argument is around wanting something "battle tested", go
>> for
>> >> slf4j-log4j. It's certainly used by more projects than logback and
>> more
>> >> people would already know it's configuration options. Personally, I
>> find
>> >> the "number of projects" argument annoying and mostly irrelevant. (and
>> at
>> >> least 2 of the "Apache 8" projects that are on the logback homepage
>> don't
>> >> use logback, they now use slf4j-log4j)
>> >>
>> >> Thus, it comes down to two major things for me:
>> >>
>> >> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
>> >> vote -1 for logback if/when presented to the PMC for approval. There
>> are
>> >> very good options that would work just as well for our needs that are
>> not
>> >> EPL.
>> >
>> >
>> > My points are:
>> >
>> > 1. that we should make sure the selected implementation passes the
>> > technical gate *first*
>> >
>>
>> Any technical definition of this gate ?
>>
>
> All integration tests pass and no significant performance regression (I
> would say >5% is significant but I agree we do not have a strict measure of
> that).
>
> My first mail on this thread is awaiting confirmation from you that log4j2
> meets the above.
>
>
>>
>> > 2. That committers should not worry about the outcome of a PMC vote when
>> > making their recommendation on implementation. If the PMC chooses to say
>> no
>> > to a specific dependency on the basis of its license *then* the community
>> > will presumably have a second option that passes the technical gate and
>> can
>> > fall back to that... But the very first question that committers should
>> > consider is the technical basis.
>> >
>> > I don't care what criteria people use as long as technical is #1.
>> >
>> >
>> >>
>> >> 2) Community - Ceki is great, no doubt about it, but at the end of the
>> >> day, logback is pretty much a one man show. Apache is more about
>> >> "community" and "community over code" and all that. I strongly prefer
>> >> something that has a community behind it, or, at the very least, is
>> open to
>> >> developing a community behind it. Major bonus points if that community
>> >> already contains Maven PMC members/committers on it. If *we* run into
>> >> issues, I strongly prefer that *we* can get those issues fixed.
>> >>
>> >> If two options are functionally and technically equivalent (within
>> >> reasonable limits), then I'll take the community driven, permissive
>> >> licensed version.
>> >
>>
>> I have already explained my opinion in other threads. So nothing more
>> to add (maybe I'm lazy for copy/paste :-))
>> I tend to follow Dan explanations as it's similar to mine.
>> So -1 for logback.
>>
>> >
>> > Thank you for stating your criteria
>> >
>> > I wish everyone else could follow your example
>> >
>> >
>> >>
>> >> That's my $0.02 worth.
>> >>
>> >> Dan
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io<javascript:;>>
>> >> wrote:
>> >>
>> >> > 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.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> Daniel Kulp
>> >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>> >> Talend Community Coder - http://coders.talend.com
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
On 11 December 2012 21:49, Olivier Lamy <ol...@apache.org> wrote:
> 2012/12/11 Stephen Connolly <st...@gmail.com>:
> > On Tuesday, 11 December 2012, Daniel Kulp wrote:
> >
> >>
> >>
> >> My thoughts:
> >> 99.5% (or more) of the maven users will not care one way or another what
> >> logging impl we use. They won't configure anything beyond -X. They
> won't
> >> try changing loggers. They won't muck with the configs. Etc.. They
> >> just run "mvn" and expect it to work.
> >>
> >> For the remaining <0.5%, no matter what we do, we will need to document
> >> things clearly about how to configure things. For these folks, they
> are
> >> generally "experts" and thus a couple extra steps to replace a logging
> >> framework, edit configs, etc… is not a big deal at all. (again,
> DOCUMENT
> >> this all clearly or provide a nice maven plugin or something to do it
> for
> >> them)
> >>
> >>
> >> My preference, in order:
> >>
> >> slf4j-jdk14
> >> slf4j-simple
> >> log4j2
> >> slf4j-log4j
> >>
> >> and then a big gap to logback.
> >>
> >> The first two are there as they would provide the least amount of "extra
> >> dependencies", complexity, etc… That said, we know slf4j-simple has
> >> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
> >> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
> >> If the entire argument is around wanting something "battle tested", go
> for
> >> slf4j-log4j. It's certainly used by more projects than logback and
> more
> >> people would already know it's configuration options. Personally, I
> find
> >> the "number of projects" argument annoying and mostly irrelevant. (and
> at
> >> least 2 of the "Apache 8" projects that are on the logback homepage
> don't
> >> use logback, they now use slf4j-log4j)
> >>
> >> Thus, it comes down to two major things for me:
> >>
> >> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
> >> vote -1 for logback if/when presented to the PMC for approval. There
> are
> >> very good options that would work just as well for our needs that are
> not
> >> EPL.
> >
> >
> > My points are:
> >
> > 1. that we should make sure the selected implementation passes the
> > technical gate *first*
> >
>
> Any technical definition of this gate ?
>
All integration tests pass and no significant performance regression (I
would say >5% is significant but I agree we do not have a strict measure of
that).
My first mail on this thread is awaiting confirmation from you that log4j2
meets the above.
>
> > 2. That committers should not worry about the outcome of a PMC vote when
> > making their recommendation on implementation. If the PMC chooses to say
> no
> > to a specific dependency on the basis of its license *then* the community
> > will presumably have a second option that passes the technical gate and
> can
> > fall back to that... But the very first question that committers should
> > consider is the technical basis.
> >
> > I don't care what criteria people use as long as technical is #1.
> >
> >
> >>
> >> 2) Community - Ceki is great, no doubt about it, but at the end of the
> >> day, logback is pretty much a one man show. Apache is more about
> >> "community" and "community over code" and all that. I strongly prefer
> >> something that has a community behind it, or, at the very least, is
> open to
> >> developing a community behind it. Major bonus points if that community
> >> already contains Maven PMC members/committers on it. If *we* run into
> >> issues, I strongly prefer that *we* can get those issues fixed.
> >>
> >> If two options are functionally and technically equivalent (within
> >> reasonable limits), then I'll take the community driven, permissive
> >> licensed version.
> >
>
> I have already explained my opinion in other threads. So nothing more
> to add (maybe I'm lazy for copy/paste :-))
> I tend to follow Dan explanations as it's similar to mine.
> So -1 for logback.
>
> >
> > Thank you for stating your criteria
> >
> > I wish everyone else could follow your example
> >
> >
> >>
> >> That's my $0.02 worth.
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io<javascript:;>>
> >> wrote:
> >>
> >> > 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.
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Logback in Maven Core
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/11 Stephen Connolly <st...@gmail.com>:
> On Tuesday, 11 December 2012, Daniel Kulp wrote:
>
>>
>>
>> My thoughts:
>> 99.5% (or more) of the maven users will not care one way or another what
>> logging impl we use. They won't configure anything beyond -X. They won't
>> try changing loggers. They won't muck with the configs. Etc.. They
>> just run "mvn" and expect it to work.
>>
>> For the remaining <0.5%, no matter what we do, we will need to document
>> things clearly about how to configure things. For these folks, they are
>> generally "experts" and thus a couple extra steps to replace a logging
>> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT
>> this all clearly or provide a nice maven plugin or something to do it for
>> them)
>>
>>
>> My preference, in order:
>>
>> slf4j-jdk14
>> slf4j-simple
>> log4j2
>> slf4j-log4j
>>
>> and then a big gap to logback.
>>
>> The first two are there as they would provide the least amount of "extra
>> dependencies", complexity, etc… That said, we know slf4j-simple has
>> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
>> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
>> If the entire argument is around wanting something "battle tested", go for
>> slf4j-log4j. It's certainly used by more projects than logback and more
>> people would already know it's configuration options. Personally, I find
>> the "number of projects" argument annoying and mostly irrelevant. (and at
>> least 2 of the "Apache 8" projects that are on the logback homepage don't
>> use logback, they now use slf4j-log4j)
>>
>> Thus, it comes down to two major things for me:
>>
>> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
>> vote -1 for logback if/when presented to the PMC for approval. There are
>> very good options that would work just as well for our needs that are not
>> EPL.
>
>
> My points are:
>
> 1. that we should make sure the selected implementation passes the
> technical gate *first*
>
Any technical definition of this gate ?
> 2. That committers should not worry about the outcome of a PMC vote when
> making their recommendation on implementation. If the PMC chooses to say no
> to a specific dependency on the basis of its license *then* the community
> will presumably have a second option that passes the technical gate and can
> fall back to that... But the very first question that committers should
> consider is the technical basis.
>
> I don't care what criteria people use as long as technical is #1.
>
>
>>
>> 2) Community - Ceki is great, no doubt about it, but at the end of the
>> day, logback is pretty much a one man show. Apache is more about
>> "community" and "community over code" and all that. I strongly prefer
>> something that has a community behind it, or, at the very least, is open to
>> developing a community behind it. Major bonus points if that community
>> already contains Maven PMC members/committers on it. If *we* run into
>> issues, I strongly prefer that *we* can get those issues fixed.
>>
>> If two options are functionally and technically equivalent (within
>> reasonable limits), then I'll take the community driven, permissive
>> licensed version.
>
I have already explained my opinion in other threads. So nothing more
to add (maybe I'm lazy for copy/paste :-))
I tend to follow Dan explanations as it's similar to mine.
So -1 for logback.
>
> Thank you for stating your criteria
>
> I wish everyone else could follow your example
>
>
>>
>> That's my $0.02 worth.
>>
>> Dan
>>
>>
>>
>>
>>
>>
>>
>>
>> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io <javascript:;>>
>> wrote:
>>
>> > 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.
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
On Tuesday, 11 December 2012, Daniel Kulp wrote:
>
>
> My thoughts:
> 99.5% (or more) of the maven users will not care one way or another what
> logging impl we use. They won't configure anything beyond -X. They won't
> try changing loggers. They won't muck with the configs. Etc.. They
> just run "mvn" and expect it to work.
>
> For the remaining <0.5%, no matter what we do, we will need to document
> things clearly about how to configure things. For these folks, they are
> generally "experts" and thus a couple extra steps to replace a logging
> framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT
> this all clearly or provide a nice maven plugin or something to do it for
> them)
>
>
> My preference, in order:
>
> slf4j-jdk14
> slf4j-simple
> log4j2
> slf4j-log4j
>
> and then a big gap to logback.
>
> The first two are there as they would provide the least amount of "extra
> dependencies", complexity, etc… That said, we know slf4j-simple has
> issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI
> case, I don't see any advantage of logback over log4j2 or slf4j-log4j.
> If the entire argument is around wanting something "battle tested", go for
> slf4j-log4j. It's certainly used by more projects than logback and more
> people would already know it's configuration options. Personally, I find
> the "number of projects" argument annoying and mostly irrelevant. (and at
> least 2 of the "Apache 8" projects that are on the logback homepage don't
> use logback, they now use slf4j-log4j)
>
> Thus, it comes down to two major things for me:
>
> 1) License issues - (sorry Stephen, this IS an issue) I fully plan to
> vote -1 for logback if/when presented to the PMC for approval. There are
> very good options that would work just as well for our needs that are not
> EPL.
My points are:
1. that we should make sure the selected implementation passes the
technical gate *first*
2. That committers should not worry about the outcome of a PMC vote when
making their recommendation on implementation. If the PMC chooses to say no
to a specific dependency on the basis of its license *then* the community
will presumably have a second option that passes the technical gate and can
fall back to that... But the very first question that committers should
consider is the technical basis.
I don't care what criteria people use as long as technical is #1.
>
> 2) Community - Ceki is great, no doubt about it, but at the end of the
> day, logback is pretty much a one man show. Apache is more about
> "community" and "community over code" and all that. I strongly prefer
> something that has a community behind it, or, at the very least, is open to
> developing a community behind it. Major bonus points if that community
> already contains Maven PMC members/committers on it. If *we* run into
> issues, I strongly prefer that *we* can get those issues fixed.
>
> If two options are functionally and technically equivalent (within
> reasonable limits), then I'll take the community driven, permissive
> licensed version.
Thank you for stating your criteria
I wish everyone else could follow your example
>
> That's my $0.02 worth.
>
> Dan
>
>
>
>
>
>
>
>
> On Dec 10, 2012, at 9:32 PM, Jason van Zyl <jason@tesla.io <javascript:;>>
> wrote:
>
> > 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.
> >
> >
> >
> >
> >
>
> --
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
Re: Logback in Maven Core
Posted by Daniel Kulp <dk...@apache.org>.
My thoughts:
99.5% (or more) of the maven users will not care one way or another what logging impl we use. They won't configure anything beyond -X. They won't try changing loggers. They won't muck with the configs. Etc.. They just run "mvn" and expect it to work.
For the remaining <0.5%, no matter what we do, we will need to document things clearly about how to configure things. For these folks, they are generally "experts" and thus a couple extra steps to replace a logging framework, edit configs, etc… is not a big deal at all. (again, DOCUMENT this all clearly or provide a nice maven plugin or something to do it for them)
My preference, in order:
slf4j-jdk14
slf4j-simple
log4j2
slf4j-log4j
and then a big gap to logback.
The first two are there as they would provide the least amount of "extra dependencies", complexity, etc… That said, we know slf4j-simple has issues. Not sure if anyone has even tried slf4j-jdk14. For our CLI case, I don't see any advantage of logback over log4j2 or slf4j-log4j. If the entire argument is around wanting something "battle tested", go for slf4j-log4j. It's certainly used by more projects than logback and more people would already know it's configuration options. Personally, I find the "number of projects" argument annoying and mostly irrelevant. (and at least 2 of the "Apache 8" projects that are on the logback homepage don't use logback, they now use slf4j-log4j)
Thus, it comes down to two major things for me:
1) License issues - (sorry Stephen, this IS an issue) I fully plan to vote -1 for logback if/when presented to the PMC for approval. There are very good options that would work just as well for our needs that are not EPL.
2) Community - Ceki is great, no doubt about it, but at the end of the day, logback is pretty much a one man show. Apache is more about "community" and "community over code" and all that. I strongly prefer something that has a community behind it, or, at the very least, is open to developing a community behind it. Major bonus points if that community already contains Maven PMC members/committers on it. If *we* run into issues, I strongly prefer that *we* can get those issues fixed.
If two options are functionally and technically equivalent (within reasonable limits), then I'll take the community driven, permissive licensed version.
That's my $0.02 worth.
Dan
On Dec 10, 2012, at 9:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
> 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.
>
>
>
>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
log4j2 at least from the feature branch works too. There was no significant
a difference in build time between 3.0.4 the log4j2 and the logback
versions, though I am not clear as to whether the log4j2 branch has been
updated with the latest fixes from the last round of 3.1.0 RCs.
It would be good if interested parties could organize relevant git branches
for people to evaluate
-Stephen
On 11 December 2012 23:00, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> FUD FUD FUD
>
> $ git clone git://github.com/qos-ch/slf4j.git
> $ cd slf4j/
> $ git checkout v1.5.11
> $ mvn -version
> Apache Maven (Logback) 3.1-SNAPSHOT
> (7f9e280522379fc0f3ac09f4d81e8188cdb54192; 2012-12-11 22:54:30+0000)
> Maven home: /Users/stephenc/apache/mvn-logback
> Java version: 1.6.0_37, vendor: Apple Inc.
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
> $ mvn clean verify
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for org.slf4j:slf4j-api:jar:1.5.11
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @
> org.slf4j:slf4j-parent:1.5.11, /Users/stephenc/github/slf4j/pom.xml, line
> 138, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-compiler-plugin is missing. @
> org.slf4j:slf4j-parent:1.5.11, /Users/stephenc/github/slf4j/pom.xml, line
> 102, column 12
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 27,
> column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @
> org.slf4j:slf4j-parent:1.5.11, /Users/stephenc/github/slf4j/pom.xml, line
> 181, column 15
> ...
> [INFO] <<< maven-source-plugin:2.2.1:jar (default) @ slf4j-migrator <<<
> [INFO]
> [INFO] --- maven-source-plugin:2.2.1:jar (default) @ slf4j-migrator ---
> [INFO] Building jar:
> /Users/stephenc/github/slf4j/slf4j-migrator/target/slf4j-migrator-1.5.11-sources.jar
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] SLF4J ............................................. SUCCESS [1.144s]
> [INFO] SLF4J API Module .................................. SUCCESS [7.549s]
> [INFO] SLF4J Simple Binding .............................. SUCCESS [0.842s]
> [INFO] SLF4J NOP Binding ................................. SUCCESS [0.730s]
> [INFO] SLF4J JDK14 Binding ............................... SUCCESS [0.888s]
> [INFO] SLF4J LOG4J-12 Binding ............................ SUCCESS [0.938s]
> [INFO] SLF4J JCL Binding ................................. SUCCESS [0.915s]
> [INFO] SLF4J Extensions Module ........................... SUCCESS [1.796s]
> [INFO] JCL 1.1.1 implemented over SLF4J .................. SUCCESS [1.027s]
> [INFO] DEPRECATED - JCL 1.0.4 implemented over SLF4J ..... SUCCESS [0.014s]
> [INFO] Log4j Implemented Over SLF4J ...................... SUCCESS [0.476s]
> [INFO] JUL to SLF4J bridge ............................... SUCCESS [0.845s]
> [INFO] SLF4J Integration tests ........................... SUCCESS [2.905s]
> [INFO] SLF4J Site ........................................ SUCCESS [0.360s]
> [INFO] SLF4J Migrator .................................... SUCCESS [1.050s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 21.810s
> [INFO] Finished at: Tue Dec 11 22:56:29 GMT 2012
> [INFO] Final Memory: 19M/81M
> [INFO]
> ------------------------------------------------------------------------
>
> I have to ask you Mark, what exactly are you on. I'm currently on
> Diclofenac 50mg three times per day but I think that I have shown that you
> can build slf4j 1.5 with a logback impl. I will check out log4j2 presently
>
>
> On 11 December 2012 22:41, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Oh dear me Mark. Please for the love of everything Maven please
>> reconsider what you just posted.
>>
>> Are you really sure that one cannot build slf4j-1.5 with the proposed
>> 3.1.0 versions?
>>
>> Please try it and if you have found an issue post the results for all to
>> see.
>>
>> I personally would be "shocked and stunned" if slf4j-1.5 fails to build
>>
>>
>> On 11 December 2012 22:29, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> You have to distinguish between plugin dependencies and project
>>> dependencies.
>>>
>>> For plugin dependencies this can get solved with a new switch in the
>>> maven-plugin-plugin.
>>> But for user projects this is more complicated. E.g you yourself would
>>> not even be able to compile a bugfix version of slf4j-1.5 anymore with this
>>> new version of maven!
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: ceki <ce...@qos.ch>
>>> > To: Maven Developers List <de...@maven.apache.org>
>>> > Cc:
>>> > Sent: Tuesday, December 11, 2012 10:13 PM
>>> > Subject: Re: Logback in Maven Core
>>> >
>>> > On 11.12.2012 21:28, Mark Struberg wrote:
>>> >
>>> >> Folks, don't you see it? we cannot use logback as this is a
>>> >> LocationAwareLogger and would break all projects which use slf4j <
>>> 1.6
>>> >> and older. Please go back to the original mail from 4 month where
>>> >> Ceki himself explained it!
>>> >
>>> > Hi Mark,
>>> >
>>> > You are assuming that a plugin somehow sees it's own version of
>>> > slf4j-api on the class path but sees logback (the version that ships**
>>> > with Maven) instead of it's preferred logging framework. Isn't that an
>>> > overly pessimistic scenario which could not occur in practice?
>>> >
>>> > **subject to approval
>>> >
>>> >> LieGrue,
>>> >> strub
>>> >
>>> > -- Ceki
>>> > 65% of statistics are made up on the spot
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
FUD FUD FUD
$ git clone git://github.com/qos-ch/slf4j.git
$ cd slf4j/
$ git checkout v1.5.11
$ mvn -version
Apache Maven (Logback) 3.1-SNAPSHOT
(7f9e280522379fc0f3ac09f4d81e8188cdb54192; 2012-12-11 22:54:30+0000)
Maven home: /Users/stephenc/apache/mvn-logback
Java version: 1.6.0_37, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
$ mvn clean verify
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.slf4j:slf4j-api:jar:1.5.11
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing. @
org.slf4j:slf4j-parent:1.5.11, /Users/stephenc/github/slf4j/pom.xml, line
138, column 15
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-compiler-plugin is missing. @
org.slf4j:slf4j-parent:1.5.11, /Users/stephenc/github/slf4j/pom.xml, line
102, column 12
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 27,
column 15
[WARNING] 'build.plugins.plugin.version' for
org.codehaus.mojo:build-helper-maven-plugin is missing. @
org.slf4j:slf4j-parent:1.5.11, /Users/stephenc/github/slf4j/pom.xml, line
181, column 15
...
[INFO] <<< maven-source-plugin:2.2.1:jar (default) @ slf4j-migrator <<<
[INFO]
[INFO] --- maven-source-plugin:2.2.1:jar (default) @ slf4j-migrator ---
[INFO] Building jar:
/Users/stephenc/github/slf4j/slf4j-migrator/target/slf4j-migrator-1.5.11-sources.jar
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] SLF4J ............................................. SUCCESS [1.144s]
[INFO] SLF4J API Module .................................. SUCCESS [7.549s]
[INFO] SLF4J Simple Binding .............................. SUCCESS [0.842s]
[INFO] SLF4J NOP Binding ................................. SUCCESS [0.730s]
[INFO] SLF4J JDK14 Binding ............................... SUCCESS [0.888s]
[INFO] SLF4J LOG4J-12 Binding ............................ SUCCESS [0.938s]
[INFO] SLF4J JCL Binding ................................. SUCCESS [0.915s]
[INFO] SLF4J Extensions Module ........................... SUCCESS [1.796s]
[INFO] JCL 1.1.1 implemented over SLF4J .................. SUCCESS [1.027s]
[INFO] DEPRECATED - JCL 1.0.4 implemented over SLF4J ..... SUCCESS [0.014s]
[INFO] Log4j Implemented Over SLF4J ...................... SUCCESS [0.476s]
[INFO] JUL to SLF4J bridge ............................... SUCCESS [0.845s]
[INFO] SLF4J Integration tests ........................... SUCCESS [2.905s]
[INFO] SLF4J Site ........................................ SUCCESS [0.360s]
[INFO] SLF4J Migrator .................................... SUCCESS [1.050s]
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 21.810s
[INFO] Finished at: Tue Dec 11 22:56:29 GMT 2012
[INFO] Final Memory: 19M/81M
[INFO]
------------------------------------------------------------------------
I have to ask you Mark, what exactly are you on. I'm currently on
Diclofenac 50mg three times per day but I think that I have shown that you
can build slf4j 1.5 with a logback impl. I will check out log4j2 presently
On 11 December 2012 22:41, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:
> Oh dear me Mark. Please for the love of everything Maven please reconsider
> what you just posted.
>
> Are you really sure that one cannot build slf4j-1.5 with the proposed
> 3.1.0 versions?
>
> Please try it and if you have found an issue post the results for all to
> see.
>
> I personally would be "shocked and stunned" if slf4j-1.5 fails to build
>
>
> On 11 December 2012 22:29, Mark Struberg <st...@yahoo.de> wrote:
>
>> You have to distinguish between plugin dependencies and project
>> dependencies.
>>
>> For plugin dependencies this can get solved with a new switch in the
>> maven-plugin-plugin.
>> But for user projects this is more complicated. E.g you yourself would
>> not even be able to compile a bugfix version of slf4j-1.5 anymore with this
>> new version of maven!
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>> > From: ceki <ce...@qos.ch>
>> > To: Maven Developers List <de...@maven.apache.org>
>> > Cc:
>> > Sent: Tuesday, December 11, 2012 10:13 PM
>> > Subject: Re: Logback in Maven Core
>> >
>> > On 11.12.2012 21:28, Mark Struberg wrote:
>> >
>> >> Folks, don't you see it? we cannot use logback as this is a
>> >> LocationAwareLogger and would break all projects which use slf4j < 1.6
>> >> and older. Please go back to the original mail from 4 month where
>> >> Ceki himself explained it!
>> >
>> > Hi Mark,
>> >
>> > You are assuming that a plugin somehow sees it's own version of
>> > slf4j-api on the class path but sees logback (the version that ships**
>> > with Maven) instead of it's preferred logging framework. Isn't that an
>> > overly pessimistic scenario which could not occur in practice?
>> >
>> > **subject to approval
>> >
>> >> LieGrue,
>> >> strub
>> >
>> > -- Ceki
>> > 65% of statistics are made up on the spot
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
Oh dear me Mark. Please for the love of everything Maven please reconsider
what you just posted.
Are you really sure that one cannot build slf4j-1.5 with the proposed 3.1.0
versions?
Please try it and if you have found an issue post the results for all to
see.
I personally would be "shocked and stunned" if slf4j-1.5 fails to build
On 11 December 2012 22:29, Mark Struberg <st...@yahoo.de> wrote:
> You have to distinguish between plugin dependencies and project
> dependencies.
>
> For plugin dependencies this can get solved with a new switch in the
> maven-plugin-plugin.
> But for user projects this is more complicated. E.g you yourself would not
> even be able to compile a bugfix version of slf4j-1.5 anymore with this new
> version of maven!
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: ceki <ce...@qos.ch>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Tuesday, December 11, 2012 10:13 PM
> > Subject: Re: Logback in Maven Core
> >
> > On 11.12.2012 21:28, Mark Struberg wrote:
> >
> >> Folks, don't you see it? we cannot use logback as this is a
> >> LocationAwareLogger and would break all projects which use slf4j < 1.6
> >> and older. Please go back to the original mail from 4 month where
> >> Ceki himself explained it!
> >
> > Hi Mark,
> >
> > You are assuming that a plugin somehow sees it's own version of
> > slf4j-api on the class path but sees logback (the version that ships**
> > with Maven) instead of it's preferred logging framework. Isn't that an
> > overly pessimistic scenario which could not occur in practice?
> >
> > **subject to approval
> >
> >> LieGrue,
> >> strub
> >
> > -- Ceki
> > 65% of statistics are made up on the spot
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Logback in Maven Core
Posted by Mark Struberg <st...@yahoo.de>.
You have to distinguish between plugin dependencies and project dependencies.
For plugin dependencies this can get solved with a new switch in the maven-plugin-plugin.
But for user projects this is more complicated. E.g you yourself would not even be able to compile a bugfix version of slf4j-1.5 anymore with this new version of maven!
LieGrue,
strub
----- Original Message -----
> From: ceki <ce...@qos.ch>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Tuesday, December 11, 2012 10:13 PM
> Subject: Re: Logback in Maven Core
>
> On 11.12.2012 21:28, Mark Struberg wrote:
>
>> Folks, don't you see it? we cannot use logback as this is a
>> LocationAwareLogger and would break all projects which use slf4j < 1.6
>> and older. Please go back to the original mail from 4 month where
>> Ceki himself explained it!
>
> Hi Mark,
>
> You are assuming that a plugin somehow sees it's own version of
> slf4j-api on the class path but sees logback (the version that ships**
> with Maven) instead of it's preferred logging framework. Isn't that an
> overly pessimistic scenario which could not occur in practice?
>
> **subject to approval
>
>> LieGrue,
>> strub
>
> -- Ceki
> 65% of statistics are made up on the spot
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by ceki <ce...@qos.ch>.
On 11.12.2012 21:28, Mark Struberg wrote:
> Folks, don't you see it? we cannot use logback as this is a
> LocationAwareLogger and would break all projects which use slf4j < 1.6
> and older. Please go back to the original mail from 4 month where
> Ceki himself explained it!
Hi Mark,
You are assuming that a plugin somehow sees it's own version of
slf4j-api on the class path but sees logback (the version that ships**
with Maven) instead of it's preferred logging framework. Isn't that an
overly pessimistic scenario which could not occur in practice?
**subject to approval
> LieGrue,
> strub
--
Ceki
65% of statistics are made up on the spot
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1 for logback
On Tue, Dec 11, 2012 at 9:28 PM, Mark Struberg <st...@yahoo.de> wrote:
> folks, don't you see it? we cannot use logback as this is a
> LocationAwareLogger and would break all projects which use slf4j < 1.6 and
> older.
> Please go back to the original mail from 4 month where Ceki himself
> explained it!
>
> So -1 on logback
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Anders Hammar <an...@hammar.net>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Tuesday, December 11, 2012 7:57 PM
> > Subject: Re: Logback in Maven Core
> >
> > I'm +1 for logback as the slf4j impl.
> >
> > /Anders
> >
> >
> > On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Logback in Maven Core
Posted by Mark Struberg <st...@yahoo.de>.
folks, don't you see it? we cannot use logback as this is a LocationAwareLogger and would break all projects which use slf4j < 1.6 and older.
Please go back to the original mail from 4 month where Ceki himself explained it!
So -1 on logback
LieGrue,
strub
----- Original Message -----
> From: Anders Hammar <an...@hammar.net>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Tuesday, December 11, 2012 7:57 PM
> Subject: Re: Logback in Maven Core
>
> I'm +1 for logback as the slf4j impl.
>
> /Anders
>
>
> On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> 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.
>>
>>
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Stephen Connolly <st...@gmail.com>.
My understanding is that whichever choice is made, there will need to be
some support code in CLI to allow for CLI options for tweaking the logging
level (i.e. -X to turn on DEBUG). As I do not yet know what that code will
look like I cannot say if a straight remove selected impl and drop in
alternative impl will work fully.
I would expect that you could replace the impl and then you would have to
configure that impl to control its logging. So my hope would be that,
assuming for the sake of an example log4j2 is chosen, you remove log4j2.jar
from the Maven CLI lib folder and add in logback.jar. At that point Maven
CLI should not blow up but -X does not affect the logging output and a new
"--quiet" option will not turn off INFO level. But through the use of
system properties or dropping in a logging configuration file into Maven's
classpath you can control logging in that regard.
I do not think developers want to support the logger implementation
specific code for multiple implementations as it just multiplies out our
testing requirements.
Note: I have my own opinion on which logging framework we should choose. I
am trying very carefully not to expose that preference in this thread
(though it should be trivial for anyone to find my opinion by searching the
recent archives) in order to allow this thread to be free from any
perceived bias from myself. I will provide details of my vote when there is
a significant engagement from the community. Do not take anything in the
above as an endorsement on my behalf of any option for the logging
framework.
-Stephen
On 11 December 2012 19:55, Dan Tran <da...@gmail.com> wrote:
> +1 on for logback.
>
> However, is it possible to switch to Log4j2 by manually repackage
> maven distribution?
>
> Thanks
>
> -D
>
> On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar <an...@hammar.net> wrote:
> > I'm +1 for logback as the slf4j impl.
> >
> > /Anders
> >
> >
> > On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Logback in Maven Core
Posted by Mark Struberg <st...@yahoo.de>.
btw, jason mentioned that lots of apache frameworks already use SLF4J. And he prominently mentioned CXF.
Now here comes the bitter truth: THEY DROPPED IT AGAIN!
They now use a java.util.logging.Logger facade to redirect to log4j, slf4j or whatever
http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/common/logging/AbstractDelegatingLogger.java
And now folks please go over and read all the reasons for this move...
Just a small pointer: Why are the following projects and others NOT using slf4j?
* MyFaces
* Tomcat
* Geronimo
* Tomee
* OpenJPA
* OpenWebBeans
* CXF
* younameit
because it doesn't work for containers in all situations.
4 Month of trying to get it working. And still there are a lot cases which are known to create problems. Doesn't that ring a bell?
I'm perfectly fine to do the same as CXF and use jul as facade and back it with SLF4J or log4j. But there are only 2 ways technically to not introduce classpath issues: jul or our very own mojo-logger facade (which is in place since 2004).
----- Original Message -----
> From: Dan Tran <da...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Tuesday, December 11, 2012 8:55 PM
> Subject: Re: Logback in Maven Core
>
> +1 on for logback.
>
> However, is it possible to switch to Log4j2 by manually repackage
> maven distribution?
>
> Thanks
>
> -D
>
> On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar <an...@hammar.net> wrote:
>> I'm +1 for logback as the slf4j impl.
>>
>> /Anders
>>
>>
>> On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io>
> wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Dan Tran <da...@gmail.com>.
+1 on for logback.
However, is it possible to switch to Log4j2 by manually repackage
maven distribution?
Thanks
-D
On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar <an...@hammar.net> wrote:
> I'm +1 for logback as the slf4j impl.
>
> /Anders
>
>
> On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io> wrote:
>
>> 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.
>>
>>
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Logback in Maven Core
Posted by Anders Hammar <an...@hammar.net>.
I'm +1 for logback as the slf4j impl.
/Anders
On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl <ja...@tesla.io> wrote:
> 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.
>
>
>
>
>
>