Re: Moving site to cms/svnpubsub
Unsure was POM XSD officially available or not from URL (as documented for example here http://maven.apache.org/pom.html#Quick_Overview): http://maven.apache.org/xsd/maven-4.0.0.xsd but it's gone too Thanks, ~t~ On Mon, Dec 10, 2012 at 3:51 PM, Olivier Lamy ol...@apache.org wrote: Hi, It's now live. http://maven.apache.org is currently under first sync (this first one can/will take a bit of time). scp deployment won't work anymore now. I will start documentation on how to use (you can read previously send links). Note: * you can still build main and doxia sites locally using mvn site * and commit files. 2012/11/29 Olivier Lamy ol...@apache.org: Hi, Reminder it's mandatory for the end of the year to move that. So I will start to ask infra for that (one volunteer to help me ? hervé as you start the poc ? ) POC is here: http://maventest.apache.org You can edit pages using bookmarklet see: https://cms.apache.org/maventest/ Other documentation: http://www.apache.org/dev/cmsref.html Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
Given that some people are already confused as to what the exact question is I think we should clarify exactly what is the decision that is being asked. There has already been a decision to use the slf4j API for logging within core. * The vast majority of plugins will still use the Maven Log interface for their logging. * A small limited number of plugins with specific needs will use the slf4j API that is exposed by core directly, but those plugins will have to do some work in order to ensure that they work with Maven pre 3.1.0 as well as Maven post 3.1.0 My understanding is that they will have to add a slf4j implementation to their dependencies... on Maven 3.1.0+ the implementation will be ignored as the slf4j-api that they see on their classpath will already have been initialized with core's implementation. On Maven pre-3.1.0 their slf4j-api will be initialized and find their slf4j implementation. * A smaller subset of plugins need to control the slf4j implementation and cannot have a different implementation. Those plugins will have to add a metadata flag requesting a classloader that is isolated from core's slf4j API. Such plugins might be redirecting log output for processing, or some other need that we have not foreseen. On Maven 3.1.0 if the metadata flag is not present the plugin will likely be borked and a newer version with the metadata flag will need to be released [Though the precise behaviour in the absence of this flag is yet to be defined] When the flag is enabled, the Maven Log interface will be the way the plugin is required to route the information it wants logged to the user through to the user. On Maven pre-3.1.0 things will be as they always were, i.e. the Maven Log interface is the way we prefer information to be logged through to the user. What is being discussed now is which *implementation* to use for the Maven CLI commands by default in core starting with Maven 3.1.0. There are a number of possible implementations: * SLF4J Simple was initially considered. This is a very limited logger but would be able to produce logging output formatted the same as Maven currently provides. *However* there is a regression caused for some of the integration tests when using SLF4J and fixing those issues currently produces performance regressions as well as the current uncertainty as to whether those fixes will be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J Simple is currently being rejected on technical grounds (but if sufficient developers really want to go with the we don't want to choose a specific implementation choice, this is the implementation you would be selecting. * Logback is being proposed by Jason. AFAIK this implementation passes on the technical criteria. In other words no failing integration tests and no significant performance regressions. * Log4j2 has been championed by Olivier. AFAIK this implementation passes on the integration tests. I am not sure of the performance technical test. One should note that Log4j2 is a new implementation and is not Log4j I hope that Olivier or somebody else can confirm the integration test status of Log4j2 as a back end implementation and provide information on the performance status of Log4j2. To my knowledge no other SLF4J implementations have been proposed, but if there are others that people want considered please provide an update here. The primary concern that Maven committers should apply is the technical merit of any proposed implementation. An implementation should be able to pass all the integration tests and not produce a significant performance regression. Developers should not concern themselves with the licensing terms of the implementation provided that the implementation is available under one of the ASL compatible licenses (i.e. Category A or Category B). If a Category B licensed implementation is chosen then for legal reasons the PMC must approve the use of that dependency. (Personally speaking, if that decision is purely based on technical grounds, I do not see why the PMC would object) Maven Committers can use other criteria in making their decision. Just ensure that the technical merit is the primary criteria and do not make the decision based on Licensing. If you are not a committer, your input is still wanted and welcome. We want this decision to be one embraced by the whole community. -Stephen On 11 December 2012 07:14, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Hi, please go for logback. I really wondered why slf4j was initially chosen at all, given logback is available and mature. We've been using logback at work in production for quite some time now and are very pleased. So yes, using logback in Maven is fine. Regards Ansgar Am 11.12.2012 03:33 schrieb Jason van Zyl ja...@tesla.io: Hi, I looked around a bit more today and I don't think SLF4J
Re: Moving site to cms/svnpubsub
99,9% sure it was with others xsds like assembly co On Tue, Dec 11, 2012 at 9:41 AM, Tamás Cservenák ta...@cservenak.netwrote: Unsure was POM XSD officially available or not from URL (as documented for example here http://maven.apache.org/pom.html#Quick_Overview): http://maven.apache.org/xsd/maven-4.0.0.xsd but it's gone too Thanks, ~t~ On Mon, Dec 10, 2012 at 3:51 PM, Olivier Lamy ol...@apache.org wrote: Hi, It's now live. http://maven.apache.org is currently under first sync (this first one can/will take a bit of time). scp deployment won't work anymore now. I will start documentation on how to use (you can read previously send links). Note: * you can still build main and doxia sites locally using mvn site * and commit files. 2012/11/29 Olivier Lamy ol...@apache.org: Hi, Reminder it's mandatory for the end of the year to move that. So I will start to ask infra for that (one volunteer to help me ? hervé as you start the poc ? ) POC is here: http://maventest.apache.org You can edit pages using bookmarklet see: https://cms.apache.org/maventest/ Other documentation: http://www.apache.org/dev/cmsref.html Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: Moving site to cms/svnpubsub
sure I will. 2012/12/11 Kristian Rosenvold kristian.rosenv...@zenior.no: If you could help me with surefire this week I would be /really/ happy and promise to study your changes so I can do it for other projects later ;) Kristian Den 11. des. 2012 kl. 00:23 skrev Olivier Lamy ol...@apache.org: I have updated documentation for publishing our main website http://maven.apache.org/developers/website/deploy-maven-website.html (do not hesitate to fix typos or improve it). And feel free to test it or write more documentation, that will be now live in only few minutes :-). We will start with Hervé configuring various poms to be able to publish sites for our sub projects with the scm-publish plugin. Hervé has some ideas (but as usual I do not agree :-) ). 2012/12/10 Olivier Lamy ol...@apache.org: Hi, It's now live. http://maven.apache.org is currently under first sync (this first one can/will take a bit of time). scp deployment won't work anymore now. I will start documentation on how to use (you can read previously send links). Note: * you can still build main and doxia sites locally using mvn site * and commit files. 2012/11/29 Olivier Lamy ol...@apache.org: Hi, Reminder it's mandatory for the end of the year to move that. So I will start to ask infra for that (one volunteer to help me ? hervé as you start the poc ? ) POC is here: http://maventest.apache.org You can edit pages using bookmarklet see: https://cms.apache.org/maventest/ Other documentation: http://www.apache.org/dev/cmsref.html Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Moving site to cms/svnpubsub
Thanks for report. Just fixed. Those files was never added in any path of our scm. (So can happen for some others files never added, I have restored /images too). Note: there is backup of our site in /www/maven-old.apache.org on people.a.o I can try to explain how that works (or at least what I have understand :-) ). maven.apache.org and maven.apache.org/doxia are now using the cms mechanism (so you can edit content within a browser) (see various links https://cms.apache.org/maven/ and https://cms.apache.org/maven-doxia/ ) Two buildbot jobs (http://ci.apache.org/builders/maven-site-staging and http://ci.apache.org/builders/maven-doxia-site-staging) build the web site and commit to https://svn.apache.org/repos/infra/websites/production/maven/ and https://svn.apache.org/repos/infra/websites/production/maven-doxia/) those svn paths are sync then to live machines. If something is not generated by buildbot jobs it will be cleaned. But as we have some sub sites we declare them to a file to prevent deletion: https://svn.apache.org/repos/asf/maven/site/trunk/content/resources/extpaths.txt 2012/12/11 Tamás Cservenák ta...@cservenak.net: Unsure was POM XSD officially available or not from URL (as documented for example here http://maven.apache.org/pom.html#Quick_Overview): http://maven.apache.org/xsd/maven-4.0.0.xsd but it's gone too Thanks, ~t~ On Mon, Dec 10, 2012 at 3:51 PM, Olivier Lamy ol...@apache.org wrote: Hi, It's now live. http://maven.apache.org is currently under first sync (this first one can/will take a bit of time). scp deployment won't work anymore now. I will start documentation on how to use (you can read previously send links). Note: * you can still build main and doxia sites locally using mvn site * and commit files. 2012/11/29 Olivier Lamy ol...@apache.org: Hi, Reminder it's mandatory for the end of the year to move that. So I will start to ask infra for that (one volunteer to help me ? hervé as you start the poc ? ) POC is here: http://maventest.apache.org You can edit pages using bookmarklet see: https://cms.apache.org/maventest/ Other documentation: http://www.apache.org/dev/cmsref.html Thanks -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
+1 for logback! -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Dec 11, 2012 at 3:18 AM, Stephen Connolly steph...@apache.orgwrote: Given that some people are already confused as to what the exact question is I think we should clarify exactly what is the decision that is being asked. There has already been a decision to use the slf4j API for logging within core. * The vast majority of plugins will still use the Maven Log interface for their logging. * A small limited number of plugins with specific needs will use the slf4j API that is exposed by core directly, but those plugins will have to do some work in order to ensure that they work with Maven pre 3.1.0 as well as Maven post 3.1.0 My understanding is that they will have to add a slf4j implementation to their dependencies... on Maven 3.1.0+ the implementation will be ignored as the slf4j-api that they see on their classpath will already have been initialized with core's implementation. On Maven pre-3.1.0 their slf4j-api will be initialized and find their slf4j implementation. * A smaller subset of plugins need to control the slf4j implementation and cannot have a different implementation. Those plugins will have to add a metadata flag requesting a classloader that is isolated from core's slf4j API. Such plugins might be redirecting log output for processing, or some other need that we have not foreseen. On Maven 3.1.0 if the metadata flag is not present the plugin will likely be borked and a newer version with the metadata flag will need to be released [Though the precise behaviour in the absence of this flag is yet to be defined] When the flag is enabled, the Maven Log interface will be the way the plugin is required to route the information it wants logged to the user through to the user. On Maven pre-3.1.0 things will be as they always were, i.e. the Maven Log interface is the way we prefer information to be logged through to the user. What is being discussed now is which *implementation* to use for the Maven CLI commands by default in core starting with Maven 3.1.0. There are a number of possible implementations: * SLF4J Simple was initially considered. This is a very limited logger but would be able to produce logging output formatted the same as Maven currently provides. *However* there is a regression caused for some of the integration tests when using SLF4J and fixing those issues currently produces performance regressions as well as the current uncertainty as to whether those fixes will be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J Simple is currently being rejected on technical grounds (but if sufficient developers really want to go with the we don't want to choose a specific implementation choice, this is the implementation you would be selecting. * Logback is being proposed by Jason. AFAIK this implementation passes on the technical criteria. In other words no failing integration tests and no significant performance regressions. * Log4j2 has been championed by Olivier. AFAIK this implementation passes on the integration tests. I am not sure of the performance technical test. One should note that Log4j2 is a new implementation and is not Log4j I hope that Olivier or somebody else can confirm the integration test status of Log4j2 as a back end implementation and provide information on the performance status of Log4j2. To my knowledge no other SLF4J implementations have been proposed, but if there are others that people want considered please provide an update here. The primary concern that Maven committers should apply is the technical merit of any proposed implementation. An implementation should be able to pass all the integration tests and not produce a significant performance regression. Developers should not concern themselves with the licensing terms of the implementation provided that the implementation is available under one of the ASL compatible licenses (i.e. Category A or Category B). If a Category B licensed implementation is chosen then for legal reasons the PMC must approve the use of that dependency. (Personally speaking, if that decision is purely based on technical grounds, I do not see why the PMC would object) Maven Committers can use other criteria in making their decision. Just ensure that the technical merit is the primary criteria and do not make the decision based on Licensing. If you are not a committer, your input is still wanted and welcome. We want this decision to be one embraced by the whole community. -Stephen On 11 December 2012 07:14, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Hi, please go for logback. I really wondered why slf4j was initially chosen at all, given logback is available and mature. We've been using logback
Re: Logback in Maven Core
+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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
Stephen, Thanks for the complete explanation, I'm a little logging beleaguered :-) On Dec 11, 2012, at 4:18 AM, Stephen Connolly steph...@apache.org wrote: Given that some people are already confused as to what the exact question is I think we should clarify exactly what is the decision that is being asked. There has already been a decision to use the slf4j API for logging within core. * The vast majority of plugins will still use the Maven Log interface for their logging. * A small limited number of plugins with specific needs will use the slf4j API that is exposed by core directly, but those plugins will have to do some work in order to ensure that they work with Maven pre 3.1.0 as well as Maven post 3.1.0 My understanding is that they will have to add a slf4j implementation to their dependencies... on Maven 3.1.0+ the implementation will be ignored as the slf4j-api that they see on their classpath will already have been initialized with core's implementation. On Maven pre-3.1.0 their slf4j-api will be initialized and find their slf4j implementation. * A smaller subset of plugins need to control the slf4j implementation and cannot have a different implementation. Those plugins will have to add a metadata flag requesting a classloader that is isolated from core's slf4j API. Such plugins might be redirecting log output for processing, or some other need that we have not foreseen. On Maven 3.1.0 if the metadata flag is not present the plugin will likely be borked and a newer version with the metadata flag will need to be released [Though the precise behaviour in the absence of this flag is yet to be defined] When the flag is enabled, the Maven Log interface will be the way the plugin is required to route the information it wants logged to the user through to the user. On Maven pre-3.1.0 things will be as they always were, i.e. the Maven Log interface is the way we prefer information to be logged through to the user. What is being discussed now is which *implementation* to use for the Maven CLI commands by default in core starting with Maven 3.1.0. There are a number of possible implementations: * SLF4J Simple was initially considered. This is a very limited logger but would be able to produce logging output formatted the same as Maven currently provides. *However* there is a regression caused for some of the integration tests when using SLF4J and fixing those issues currently produces performance regressions as well as the current uncertainty as to whether those fixes will be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J Simple is currently being rejected on technical grounds (but if sufficient developers really want to go with the we don't want to choose a specific implementation choice, this is the implementation you would be selecting. * Logback is being proposed by Jason. AFAIK this implementation passes on the technical criteria. In other words no failing integration tests and no significant performance regressions. * Log4j2 has been championed by Olivier. AFAIK this implementation passes on the integration tests. I am not sure of the performance technical test. One should note that Log4j2 is a new implementation and is not Log4j I hope that Olivier or somebody else can confirm the integration test status of Log4j2 as a back end implementation and provide information on the performance status of Log4j2. To my knowledge no other SLF4J implementations have been proposed, but if there are others that people want considered please provide an update here. The primary concern that Maven committers should apply is the technical merit of any proposed implementation. An implementation should be able to pass all the integration tests and not produce a significant performance regression. Developers should not concern themselves with the licensing terms of the implementation provided that the implementation is available under one of the ASL compatible licenses (i.e. Category A or Category B). If a Category B licensed implementation is chosen then for legal reasons the PMC must approve the use of that dependency. (Personally speaking, if that decision is purely based on technical grounds, I do not see why the PMC would object) Maven Committers can use other criteria in making their decision. Just ensure that the technical merit is the primary criteria and do not make the decision based on Licensing. If you are not a committer, your input is still wanted and welcome. We want this decision to be one embraced by the whole community. -Stephen On 11 December 2012 07:14, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Hi, please go for logback. I really wondered why slf4j was initially chosen at all, given logback is available and mature. We've been using logback at
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.
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 and...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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 dant...@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 and...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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 and...@hammar.net To: Maven Developers List dev@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
+1 for logback On Tue, Dec 11, 2012 at 9:28 PM, Mark Struberg strub...@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 and...@hammar.net To: Maven Developers List dev@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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 dant...@gmail.com To: Maven Developers List dev@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 and...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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 ja...@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
Re: Logback in Maven Core
2012/12/11 Stephen Connolly stephen.alan.conno...@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 ja...@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
Re: Logback in Maven Core
On 11 December 2012 21:49, Olivier Lamy ol...@apache.org wrote: 2012/12/11 Stephen Connolly stephen.alan.conno...@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 ja...@tesla.iojavascript:; 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
Re: Logback in Maven Core
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 stephen.alan.conno...@gmail.com wrote: On 11 December 2012 21:49, Olivier Lamy ol...@apache.org wrote: 2012/12/11 Stephen Connolly stephen.alan.conno...@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
Re: Logback in Maven Core
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 c...@qos.ch To: Maven Developers List dev@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies bimargul...@gmail.comwrote: 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
On Dec 11, 2012, at 5:07 PM, Benson Margulies bimargul...@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 stephen.alan.conno...@gmail.com wrote: On 11 December 2012 21:49, Olivier Lamy ol...@apache.org wrote: 2012/12/11 Stephen Connolly stephen.alan.conno...@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
Re: Logback in Maven Core
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 bimargul...@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 stephen.alan.conno...@gmail.com wrote: On 11 December 2012 21:49, Olivier Lamy ol...@apache.org wrote: 2012/12/11 Stephen Connolly stephen.alan.conno...@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
Re: Logback in Maven Core
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 strub...@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 c...@qos.ch To: Maven Developers List dev@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies bimargul...@gmail.comwrote: 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 stephen.alan.conno...@gmail.com wrote: On 11 December 2012 21:49, Olivier Lamy ol...@apache.org wrote: 2012/12/11 Stephen Connolly stephen.alan.conno...@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
Re: Logback in Maven Core
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+) 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.conno...@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 strub...@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 c...@qos.ch To: Maven Developers List dev@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
Re: Logback in Maven Core
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.conno...@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+) 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.conno...@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 strub...@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 c...@qos.ch To: Maven Developers List dev@maven.apache.org Cc: Sent:
Re: Logback in Maven Core
OK. In the absence of anyone else giving some numbers I have been running some tests. I have been comparing 3.0.4 with logback (using git hash 7f9e280522379fc0f3ac09f4d81e8188cdb54192) and log4j (using git hash 0f71ae559e19aa3eb5e4f5c981d9e20e63cc2e3e) The first test was building GIT hash of e20a42cbd871de86e9e77fe9900e1a2829177125 of Jenkins with the following command line: mvn -o -DskipTests clean verify [Testing a long build under normal conditions] The consistent times (i.e. repeated runs after discarding the first) are: 3.0.4: 1min18sec logback: 1min13sec log4j2: 1min34sec The second test was building GIT hash 85dd6e37456d30d2661e10b044efa9036c528023 of jszip-maven-plugin (@jszip.org) with the following command line: mvn -o -X clean verify -DskipTests -Dinvoker.skip [Testing heavy logging] 3.0.4: 12.1sec logback: 12.2sec log4j2: 12.5sec Notes: 1. With -X logback spews forth a lot more shite at the end of the build. This is just an observation and I assume it will be tidied up before there would be a release if logback is chosen. 2. I am unsure if the log4j2 branch I tested is current with regard to the regression fixes in the logback branch... or even if I have picked the correct logback branch. 3. Slightly concerned with the jenkins build time with log4j2... that looks like more than a 5% regression. It would be good if somebody else can confirm this result as it could be the background gremlins struck at the time I was trying the log4j2 builds On 11 December 2012 09:18, Stephen Connolly steph...@apache.org wrote: Given that some people are already confused as to what the exact question is I think we should clarify exactly what is the decision that is being asked. There has already been a decision to use the slf4j API for logging within core. * The vast majority of plugins will still use the Maven Log interface for their logging. * A small limited number of plugins with specific needs will use the slf4j API that is exposed by core directly, but those plugins will have to do some work in order to ensure that they work with Maven pre 3.1.0 as well as Maven post 3.1.0 My understanding is that they will have to add a slf4j implementation to their dependencies... on Maven 3.1.0+ the implementation will be ignored as the slf4j-api that they see on their classpath will already have been initialized with core's implementation. On Maven pre-3.1.0 their slf4j-api will be initialized and find their slf4j implementation. * A smaller subset of plugins need to control the slf4j implementation and cannot have a different implementation. Those plugins will have to add a metadata flag requesting a classloader that is isolated from core's slf4j API. Such plugins might be redirecting log output for processing, or some other need that we have not foreseen. On Maven 3.1.0 if the metadata flag is not present the plugin will likely be borked and a newer version with the metadata flag will need to be released [Though the precise behaviour in the absence of this flag is yet to be defined] When the flag is enabled, the Maven Log interface will be the way the plugin is required to route the information it wants logged to the user through to the user. On Maven pre-3.1.0 things will be as they always were, i.e. the Maven Log interface is the way we prefer information to be logged through to the user. What is being discussed now is which *implementation* to use for the Maven CLI commands by default in core starting with Maven 3.1.0. There are a number of possible implementations: * SLF4J Simple was initially considered. This is a very limited logger but would be able to produce logging output formatted the same as Maven currently provides. *However* there is a regression caused for some of the integration tests when using SLF4J and fixing those issues currently produces performance regressions as well as the current uncertainty as to whether those fixes will be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J Simple is currently being rejected on technical grounds (but if sufficient developers really want to go with the we don't want to choose a specific implementation choice, this is the implementation you would be selecting. * Logback is being proposed by Jason. AFAIK this implementation passes on the technical criteria. In other words no failing integration tests and no significant performance regressions. * Log4j2 has been championed by Olivier. AFAIK this implementation passes on the integration tests. I am not sure of the performance technical test. One should note that Log4j2 is a new implementation and is not Log4j I hope that Olivier or somebody else can confirm the integration test status of Log4j2 as a back end implementation and provide information on the performance status of Log4j2. To my
Re: Logback in Maven Core
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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 herve.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks,
Re: Logback in Maven Core
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 herve.bout...@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
Re: Logback in Maven Core
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.conno...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
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.conno...@gmail.comjavascript:; : 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-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: A very interesting performance regression in 3.1 embedded mode
how much memory will be freed by the soft reference? if it's not a big chunk, most likely not worth it, soft references are released only when your VM is really, really in trouble. by the time it gets released, you've been slowed down by repeatedly hitting the ceiling of your memory and CGed frequently. just an illustrative story, most likely not related to this usecase but still interesting while embedding maven in netbeans, we've SoftReferenced MavenProject at some point in time. MavenProjects can hold a big object tree, mostly via the cache in ProjectBuildingRequest. So once you run out of memory, the SRs get dropped however sometimes the MP instances are again immediately required, so they are loaded again. And dropped. And loaded and the IDE grinds to a halt. In some cases, one gets OOME fairly fast, but in others it can take fairly long. BTW we don't embed maven builds, just MavenProject loading in netbeans Milos On Sun, Dec 9, 2012 at 11:04 PM, Christian Schulte c...@schulte.it wrote: Am 12/09/12 22:58, schrieb Kristian Rosenvold: Anyone else have any ideas about eviction strategies ? Without having looked at the code. GC driven by using soft references. -- Christian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
