Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
The cycle for 3.1.0 is the cycle that should be happening to prevent something we're not happy with from being released. Unlike, say, the compiler plugin which was actually released without much review only for Dan to discover after the fact it doesn't work as advertised[1]. Well, the incremental work is not yet finished. And even if the maven-compiler-plugin works a bit to eagerly today this is much less of a problem than the previous behaviour where it didn't properly detect changes and just did not compile at all, creating broken jars, wars, ears, etc if you did not do a full clean upfront... We added a few ITs for it, but obviously not enough. Hope those additional changes are also backed by ITs. LieGrue, strub From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Saturday, December 8, 2012 6:22 PM Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 Nothing has been released yet. This is what this cycle is for and frankly after 11 months of not releasing while adding JSR330 and SLF4J it's to be expected. But Hervé is working on it and I'm fixing up the error Kristian verified so it's getting review and if it takes 5 more re-spins so be it. The cycle for 3.1.0 is the cycle that should be happening to prevent something we're not happy with from being released. Unlike, say, the compiler plugin which was actually released without much review only for Dan to discover after the fact it doesn't work as advertised[1]. It always happens where after a huge hiatus no one really thinks about the release until it starts happening and then everyone wants things put in. We decided to call it 3.1.0 which to me signifies some breakage. For me that is the SLF4J API being used correctly and potentially breaking people. Hervé wants to try and preserve existing behavior which is fine. No rush and he's going to try and implement that. All in all we have still only seen one breakage in the field from the misuse of the SLF4J API. So I would hardly call this the worst state the core's been in. The only way to figure out what works, or doesn't, is to make a sample set of plugins with the various options for logging and validate their behavour. I think we should also consider calling this 3.0.5 because there are probably a lot of behaviours we do want to change. A couple things I can think of are not automatically downloading snapshots every 24 hours, or changing the behaviour of local downloads to check the SHA1 and not the server it came from. These two behaviours cause lots of problems. If we collected all those together and wanted to implement them I think that is a reason to change a major version. Most users don't care about our API changes they care about feature changes and behavioural changes. People are going to look at 3.1.0 and ask what's different for them and the answer is nothing really. [1]: https://jira.codehaus.org/browse/MCOMPILER-187 This is whole point of this cycle. Nothing has been released yet, folks have been reviewing it and we're now fixing more things. On Dec 7, 2012, at 9:39 AM, Mark Struberg strub...@yahoo.de wrote: still there have been twice as many problem reports as +1. Afaik we've never shipped a release in such a bad state to be honest. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Friday, December 7, 2012 3:04 PM Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - 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: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
AIX still does not do well with ANSI style colour. And I wonder how Jenkins would cope parsing the output. Seriously 2013 soon or not, don't break the output and introduce crap into the output stream. Sent from my iPhone On 08/12/2012, at 10:14 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - 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
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Disable color by default in batch mode then. I suppose we could detect is users are running AmigaOS or aix and disable by default there too. Kristian Den 8. des. 2012 kl. 12:34 skrev Chris Graham chrisgw...@gmail.com: AIX still does not do well with ANSI style colour. And I wonder how Jenkins would cope parsing the output. Seriously 2013 soon or not, don't break the output and introduce crap into the output stream. Sent from my iPhone On 08/12/2012, at 10:14 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
In jenkins you have a Jansi plugin that interprets ANSI codes and create colors in output. I'm using it and it is working fine. For maven there was a customizable step to create colors in the console. We'll need to find a solution to not have a conflict. - Arnaud Le 8 déc. 2012 à 12:34, Chris Graham chrisgw...@gmail.com a écrit : AIX still does not do well with ANSI style colour. And I wonder how Jenkins would cope parsing the output. Seriously 2013 soon or not, don't break the output and introduce crap into the output stream. Sent from my iPhone On 08/12/2012, at 10:14 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To unsubscribe, e-mail:
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
And windows which has a support near to the Amiga ;) - Arnaud Le 8 déc. 2012 à 12:55, Kristian Rosenvold kristian.rosenv...@zenior.no a écrit : Disable color by default in batch mode then. I suppose we could detect is users are running AmigaOS or aix and disable by default there too. Kristian Den 8. des. 2012 kl. 12:34 skrev Chris Graham chrisgw...@gmail.com: AIX still does not do well with ANSI style colour. And I wonder how Jenkins would cope parsing the output. Seriously 2013 soon or not, don't break the output and introduce crap into the output stream. Sent from my iPhone On 08/12/2012, at 10:14 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I fear meeting the millitant arch-Linux users running in strict C64 emulation. Maybe just enable colour by defalt for all fruity computers ? K Den 8. des. 2012 kl. 13:10 skrev Arnaud Héritier aherit...@gmail.com: And windows which has a support near to the Amiga ;) - Arnaud Le 8 déc. 2012 à 12:55, Kristian Rosenvold kristian.rosenv...@zenior.no a écrit : Disable color by default in batch mode then. I suppose we could detect is users are running AmigaOS or aix and disable by default there too. Kristian Den 8. des. 2012 kl. 12:34 skrev Chris Graham chrisgw...@gmail.com: AIX still does not do well with ANSI style colour. And I wonder how Jenkins would cope parsing the output. Seriously 2013 soon or not, don't break the output and introduce crap into the output stream. Sent from my iPhone On 08/12/2012, at 10:14 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something)
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Lol. I think it will be really safer to have it off by default in 3.2 and we might change it in another version depending of the community feedback. But for all if that it won't be before 2013. - Arnaud Le 8 déc. 2012 à 13:24, Kristian Rosenvold kristian.rosenv...@zenior.no a écrit : I fear meeting the millitant arch-Linux users running in strict C64 emulation. Maybe just enable colour by defalt for all fruity computers ? K Den 8. des. 2012 kl. 13:10 skrev Arnaud Héritier aherit...@gmail.com: And windows which has a support near to the Amiga ;) - Arnaud Le 8 déc. 2012 à 12:55, Kristian Rosenvold kristian.rosenv...@zenior.no a écrit : Disable color by default in batch mode then. I suppose we could detect is users are running AmigaOS or aix and disable by default there too. Kristian Den 8. des. 2012 kl. 12:34 skrev Chris Graham chrisgw...@gmail.com: AIX still does not do well with ANSI style colour. And I wonder how Jenkins would cope parsing the output. Seriously 2013 soon or not, don't break the output and introduce crap into the output stream. Sent from my iPhone On 08/12/2012, at 10:14 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: Seriously this sounds like something you'd want to configure i. MAVEN_OPTS, so I'd be inclined to do color by default in 2012, soon 2013. K Den 8. des. 2012 kl. 11:14 skrev Chris Graham chrisgw...@gmail.com: Which is what I thought. +1 to off by default then. Sent from my iPhone On 08/12/2012, at 9:11 PM, Arnaud Héritier aherit...@gmail.com wrote: http://en.m.wikipedia.org/wiki/ANSI_escape_code It adds some extras character that you'll see if the console doesn't support it - Arnaud Le 8 déc. 2012 à 11:03, Chris Graham chrisgw...@gmail.com a écrit : I'd like to know how it is implemented and what happens when it is run on a terminal that does not support it. -Chris Sent from my iPhone On 08/12/2012, at 8:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Le vendredi 7 décembre 2012 09:32:33 Jason van Zyl a écrit : Hervé I will assume you're looking at this. Let me know if you need any help. yes, I'm working on it from latest discussion, the ideal is: 1. compatibility: for plugin descriptors without information, don't expose core's slf4j-api, like it has always been the case 2. default on: when using future plugin-tools 3.3, the descriptor generated by default will enable core's slf4j-api explosition, plugin developper will need to add an annotation to hide core's slf4j-api Strategies to write a plugin using slf4j-api from core without requiring Maven 3.1 still need to be found: I personnally don't see how to do that. That's why I wrote it in [1] Of course, this will only work when run under Maven 3.1.0, then this technique can be used safely only in Maven core components. Regards, Hervé [1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-embedder/logging.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
+1, that sounds like a good balance between old compat behaviour and moving forward! Strategies to write a plugin using slf4j-api from core without requiring Maven 3.1 still need to be found: Maybe that's easier than you think. Just declare an slf4j-api dependency to the plugin. If the core-realm exposes it then the classes from the core realm will be taken anyway (parent-first). In maven 3.1 which doesn't expose it the dependency will kick in. LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Developers List dev@maven.apache.org Cc: Sent: Saturday, December 8, 2012 3:22 PM Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 Le vendredi 7 décembre 2012 09:32:33 Jason van Zyl a écrit : Hervé I will assume you're looking at this. Let me know if you need any help. yes, I'm working on it from latest discussion, the ideal is: 1. compatibility: for plugin descriptors without information, don't expose core's slf4j-api, like it has always been the case 2. default on: when using future plugin-tools 3.3, the descriptor generated by default will enable core's slf4j-api explosition, plugin developper will need to add an annotation to hide core's slf4j-api Strategies to write a plugin using slf4j-api from core without requiring Maven 3.1 still need to be found: I personnally don't see how to do that. That's why I wrote it in [1] Of course, this will only work when run under Maven 3.1.0, then this technique can be used safely only in Maven core components. Regards, Hervé [1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-embedder/logging.html - 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: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On Dec 8, 2012, at 9:22 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le vendredi 7 décembre 2012 09:32:33 Jason van Zyl a écrit : Hervé I will assume you're looking at this. Let me know if you need any help. yes, I'm working on it from latest discussion, the ideal is: 1. compatibility: for plugin descriptors without information, don't expose core's slf4j-api, like it has always been the case If this is the case we are not changing any APIs so we might want to consider actually calling this 3.0.5 and not 3.1.0 because there is no breakage. Just need to account for the following cases: - Mojo.getLog(): does not require a dependency on SLF4J API - @Inject: requires a dependency on SLF4J API - LoggerFactory.getLogger: requires a dependency on SLF4J API 2. default on: when using future plugin-tools 3.3, the descriptor generated by default will enable core's slf4j-api explosition, plugin developper will need to add an annotation to hide core's slf4j-api Strategies to write a plugin using slf4j-api from core without requiring Maven 3.1 still need to be found: I personnally don't see how to do that. Where SLF4J can be initialized on a per classloader basis. So if a plugin descriptor says use SLF4J from core and it runs in 3.1 it will come through the core. In a version of Maven that does not use SLF4J provided the plugin descriptor parser gracefully ignores the flag then SLF4J can be initialized in the plugin classloader and it should be fine. The output will be coming out of two different systems so I'm not sure if you can aggregate it, if we want to bother, but I think SLF4J will come up properly in a version prior to 3.1. That's why I wrote it in [1] Of course, this will only work when run under Maven 3.1.0, then this technique can be used safely only in Maven core components. Regards, Hervé [1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-embedder/logging.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Nothing has been released yet. This is what this cycle is for and frankly after 11 months of not releasing while adding JSR330 and SLF4J it's to be expected. But Hervé is working on it and I'm fixing up the error Kristian verified so it's getting review and if it takes 5 more re-spins so be it. The cycle for 3.1.0 is the cycle that should be happening to prevent something we're not happy with from being released. Unlike, say, the compiler plugin which was actually released without much review only for Dan to discover after the fact it doesn't work as advertised[1]. It always happens where after a huge hiatus no one really thinks about the release until it starts happening and then everyone wants things put in. We decided to call it 3.1.0 which to me signifies some breakage. For me that is the SLF4J API being used correctly and potentially breaking people. Hervé wants to try and preserve existing behavior which is fine. No rush and he's going to try and implement that. All in all we have still only seen one breakage in the field from the misuse of the SLF4J API. So I would hardly call this the worst state the core's been in. The only way to figure out what works, or doesn't, is to make a sample set of plugins with the various options for logging and validate their behavour. I think we should also consider calling this 3.0.5 because there are probably a lot of behaviours we do want to change. A couple things I can think of are not automatically downloading snapshots every 24 hours, or changing the behaviour of local downloads to check the SHA1 and not the server it came from. These two behaviours cause lots of problems. If we collected all those together and wanted to implement them I think that is a reason to change a major version. Most users don't care about our API changes they care about feature changes and behavioural changes. People are going to look at 3.1.0 and ask what's different for them and the answer is nothing really. [1]: https://jira.codehaus.org/browse/MCOMPILER-187 This is whole point of this cycle. Nothing has been released yet, folks have been reviewing it and we're now fixing more things. On Dec 7, 2012, at 9:39 AM, Mark Struberg strub...@yahoo.de wrote: still there have been twice as many problem reports as +1. Afaik we've never shipped a release in such a bad state to be honest. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Friday, December 7, 2012 3:04 PM Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed. Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, December 7, 2012 12:48 PM Subject: Re: [VOTE] Maven 3.1.0 But not all of those *need to*. At least until now they have needed to, but going forward they may not need to if we are giving them an slf4j impl to hang their hat off. There will always be some special case plugins that have a legitimate need to do funky logging stuff. We need a strategy for those plugins. Jason's proposal for those cases was that they should fork a JVM. That works if you don't need to channel objects back and forth. For some of the plugins wanting to do 'live development' style work (I am thinking my jszip.org experiments - I have some plans and experiments that I haven't even pushed to there yet ;-) ) forking a JVM is a bad plan, as you then have to basically resort to RMI to control the forked JVM... More ports and more sockets and more
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, December 7, 2012 12:48 PM Subject: Re: [VOTE] Maven 3.1.0 But not all of those *need to*. At least until now they have needed to, but going forward they may not need to if we are giving them an slf4j impl to hang their hat off. There will always be some special case plugins that have a legitimate need to do funky logging stuff. We need a strategy for those plugins. Jason's proposal for those cases was that they should fork a JVM. That works if you don't need to channel objects back and forth. For some of the plugins wanting to do 'live development' style work (I am thinking my
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
still there have been twice as many problem reports as +1. Afaik we've never shipped a release in such a bad state to be honest. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Friday, December 7, 2012 3:04 PM Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed. Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday,
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
The version that is currently staged (code name alpha-5 in my book) has an unsolved problem with the logging and verifier. I assume we'll stage a new version (code name beta-1) when that's done, at which point I'm more than ready to ship. I'm not fixing any more stuff on core now, and I'm half-assuming jason will fix the logging. Jason, do ping me on irc if you need a second set of eyes on solving the problem, even though I'm incompetent with logging ;) Kristian 2012/12/7 Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristiathe loggingn found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, December 7, 2012 12:48 PM Subject: Re: [VOTE] Maven 3.1.0 But not all of those *need to*. At
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I mentioned to Kristian that it wouldn't be hard to fix and that I would fix it before we released. Just been traveling this week. I'll fix it this weekend when I get home. On Dec 7, 2012, at 6:04 AM, Benson Margulies bimargul...@gmail.com wrote: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, December 7, 2012 12:48 PM Subject: Re: [VOTE] Maven 3.1.0 But not all of those *need to*. At least until now they have needed to, but going forward they may not need to if we are giving them an slf4j impl to hang their hat off. There will always be some special case plugins that have a legitimate need to do funky logging stuff. We need a strategy for those plugins. Jason's proposal for those cases was that they should fork a JVM. That works if you don't need to channel objects back and forth.
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Kristian, I'm going to look at problem with the logging while embedding and Hervé wants to look at the SLF4J isolation. From what I understand in talking to Ceki, for each classloader SLF4J can be initialized so it appears theoretically possible to block the all SLF4J from reaching a plugin and it will still be able to initialized its own SLF4J system though it will not be connected to the core's. So then it's a matter of deciding on sensible defaults and I agree with Anders here in that the default should be to pass on the core's SLF4J implementation. I think exceptional cases should use a flag for exceptional cases. This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. Hervé I will assume you're looking at this. Let me know if you need any help. I don't plan on introducing a logging framework in this version. That's a subsequent discussion. On Dec 7, 2012, at 7:39 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The version that is currently staged (code name alpha-5 in my book) has an unsolved problem with the logging and verifier. I assume we'll stage a new version (code name beta-1) when that's done, at which point I'm more than ready to ship. I'm not fixing any more stuff on core now, and I'm half-assuming jason will fix the logging. Jason, do ping me on irc if you need a second set of eyes on solving the problem, even though I'm incompetent with logging ;) Kristian 2012/12/7 Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristiathe loggingn found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. I'm thinking this will introduce another problem. If a plugin wants to use slf4j for logging instead of Plexus logger, but want the logging to be handled by core's logging. They would then need to declare a dependency to slf4j-api. If they're only supporting v3.1+, then they could declare a provided scope dependency and not include a dep to an impl. But if they want their plugin to work with older Maven versions as well (which they very likely want), then they need to have a compile scope dependency to slf4j AND an impl. And with the idea above, v3.1 would then block slf4j from the plugin's classloader. Thus, they're not using core's logging. We're then back to the idea of these plugin having force core's slf4j to be available, through some flag or similar. Which is the wrong way I think. At least ideally. /Anders Hervé I will assume you're looking at this. Let me know if you need any help. I don't plan on introducing a logging framework in this version. That's a subsequent discussion. On Dec 7, 2012, at 7:39 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The version that is currently staged (code name alpha-5 in my book) has an unsolved problem with the logging and verifier. I assume we'll stage a new version (code name beta-1) when that's done, at which point I'm more than ready to ship. I'm not fixing any more stuff on core now, and I'm half-assuming jason will fix the logging. Jason, do ping me on irc if you need a second set of eyes on solving the problem, even though I'm incompetent with logging ;) Kristian 2012/12/7 Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristiathe loggingn found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Why don't we make some example plugins to illustrate? I'll started when I get back home, but if you want to illustrate with an actual plugin that would be very helpful and then we can test their with our examples and then we can turn them into ITs. On Dec 7, 2012, at 9:52 AM, Anders Hammar and...@hammar.net wrote: This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. I'm thinking this will introduce another problem. If a plugin wants to use slf4j for logging instead of Plexus logger, but want the logging to be handled by core's logging. They would then need to declare a dependency to slf4j-api. If they're only supporting v3.1+, then they could declare a provided scope dependency and not include a dep to an impl. But if they want their plugin to work with older Maven versions as well (which they very likely want), then they need to have a compile scope dependency to slf4j AND an impl. And with the idea above, v3.1 would then block slf4j from the plugin's classloader. Thus, they're not using core's logging. We're then back to the idea of these plugin having force core's slf4j to be available, through some flag or similar. Which is the wrong way I think. At least ideally. /Anders Hervé I will assume you're looking at this. Let me know if you need any help. I don't plan on introducing a logging framework in this version. That's a subsequent discussion. On Dec 7, 2012, at 7:39 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The version that is currently staged (code name alpha-5 in my book) has an unsolved problem with the logging and verifier. I assume we'll stage a new version (code name beta-1) when that's done, at which point I'm more than ready to ship. I'm not fixing any more stuff on core now, and I'm half-assuming jason will fix the logging. Jason, do ping me on irc if you need a second set of eyes on solving the problem, even though I'm incompetent with logging ;) Kristian 2012/12/7 Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristiathe loggingn found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On 07.12.2012 18:32, Jason van Zyl wrote: Kristian, I'm going to look at problem with the logging while embedding and Hervé wants to look at the SLF4J isolation. From what I understand in talking to Ceki, for each classloader SLF4J can be initialized so it appears theoretically possible to block the all SLF4J from reaching a plugin and it will still be able to initialized its own SLF4J system though it will not be connected to the core's. So then it's a matter of deciding on sensible defaults and I agree with Anders here in that the default should be to pass on the core's SLF4J implementation. I think exceptional cases should use a flag for exceptional cases. This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. The above seems very reasonable. I hesitate to bring up another angle to this already heated debate. If it were up to me which it clearly is not, I'd go with exporting slf4j-api and the underlying logging framework to all plugins without hindrance. This would translate into the following worse-is-better [1] logging policy: As of 3.1.0. Maven exports its SLF4J logging environment to its plugins. Plugins are encouraged to use this SLF4J logging environment. They may attempt to configure this environment but should not blindly assume that the underlying logging framework is the default logging framework shipping with Maven. This policy would break the current Sonar plugin. Although I imagine a new version of Sonar would be released within weeks including the relevant fix. After a short adaptation period, I'd expect the rare plugins doing their own logging to fall in line with the worse-is-better logging policy outlined above. The alternative policy outlined by Jason while offering compatibility, would be murkier, at least to the uninitiated. [1] http://en.wikipedia.org/wiki/Worse_is_better Hervé I will assume you're looking at this. Let me know if you need any help. I don't plan on introducing a logging framework in this version. That's a subsequent discussion. -- 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: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On 07.12.2012 18:52, Anders Hammar wrote: This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. I'm thinking this will introduce another problem. If a plugin wants to use slf4j for logging instead of Plexus logger, but want the logging to be handled by core's logging. They would then need to declare a dependency to slf4j-api. If they're only supporting v3.1+, then they could declare a provided scope dependency and not include a dep to an impl. But if they want their plugin to work with older Maven versions as well (which they very likely want), then they need to have a compile scope dependency to slf4j AND an impl. So true. Every plugin would want to be compatible with Maven 3.1 as well as older versions. As such, I withdraw by earlier worse-is-better logging policy. /Anders -- 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: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, December 7, 2012 12:48 PM Subject: Re: [VOTE] Maven 3.1.0 But not all of those *need to*. At least until now they have needed to, but going forward they may not need to if we are giving them an slf4j impl to hang their hat off. There will always be some special case plugins that have a legitimate
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On Fri, Dec 7, 2012 at 3:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) I am -1 to a colored logger by default. The results look awful in circumstances that I spend time in, like emacs buffers. I think that we're much further from consensus about the presentation and management of a colored logger than we are from getting the base technology pushed. Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io: On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io: On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
From this user's POV, I want colors out of the box, just like you get colors out of the box with the git CLI. You do not have to turn on anything, it just works. Gary On Fri, Dec 7, 2012 at 4:03 PM, Robert Scholte rfscho...@apache.org wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io: On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Do you still watch TV in black and white? ;) On Fri, Dec 7, 2012 at 4:28 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
+1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Well, then at least a property to be set in ~/.m2/settings.xml to switch colors on would be nice :-). I for one would be much more interested in introducing a switch which allows to suppress INFO but not WARN :-). Regards Mirko On Fri, Dec 7, 2012 at 10:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Even if I like the colorized console and couldn't leave without it now I would probably vote in favor to have it off by default because : * It is difficult to define the default font color that won't be unreadable on the user console (white on white, ) * Like always, windows sucks and I didn't succeeded to have it working with Jansi on a Windows XP 64b and saw a bug reported on Windows 7 64b. If this is off by default, I would like to be able to activate it by a little config change in the distro or better with a system property or a setting entry to not have to update the config each time I upgrade ( or rebuild ) Maven Arnaud On Fri, Dec 7, 2012 at 10:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
2012/12/7 Gary Gregory garydgreg...@gmail.com: Do you still watch TV in black and white? ;) Hey, does your TV have *both* black and white ??? Insert favourite dilbert quote about programming in the real old days when we only had zeros Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Colour can grab your attention. Sometimes you don't want your attention grabbed. A build log is quite often in my opinion a bad place to grab your attention. That failure at the end will grab my attention just fine. There are times when I might like a colourised log... But more often I prefer to be able to just change the logging levels, or use the terminal's find feature On Friday, 7 December 2012, Gary Gregory wrote: Do you still watch TV in black and white? ;) On Fri, Dec 7, 2012 at 4:28 PM, Jesse McConnell jesse.mcconn...@gmail.com javascript:;wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem -- E-Mail: garydgreg...@gmail.com javascript:; | ggreg...@apache.orgjavascript:; JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
For me the most interesting is to grab warnings. Like you you cannot miss errors :-) The problem is that we cannot just display warnings because we loose the context where they occur (the module or any others details that might be in INFO level). Nowadays warnings are lost in too many logs and not often analyzed by developers Arnaud On Sat, Dec 8, 2012 at 12:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Colour can grab your attention. Sometimes you don't want your attention grabbed. A build log is quite often in my opinion a bad place to grab your attention. That failure at the end will grab my attention just fine. There are times when I might like a colourised log... But more often I prefer to be able to just change the logging levels, or use the terminal's find feature On Friday, 7 December 2012, Gary Gregory wrote: Do you still watch TV in black and white? ;) On Fri, Dec 7, 2012 at 4:28 PM, Jesse McConnell jesse.mcconn...@gmail.com javascript:;wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem -- E-Mail: garydgreg...@gmail.com javascript:; | ggreg...@apache.org javascript:; JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
As christmas is near I just start wishing for WARN on the console and INFO going to target/maven.TIMESTAMP.log. The biggest problem I see: most often the SUTs in surefire executions just spoil the whole console log when testing error situations because no one uses a logback-test.xml. Regards Mirko -- Sent from my mobile On Dec 8, 2012 12:24 AM, Arnaud Héritier aherit...@gmail.com wrote: For me the most interesting is to grab warnings. Like you you cannot miss errors :-) The problem is that we cannot just display warnings because we loose the context where they occur (the module or any others details that might be in INFO level). Nowadays warnings are lost in too many logs and not often analyzed by developers Arnaud On Sat, Dec 8, 2012 at 12:14 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Colour can grab your attention. Sometimes you don't want your attention grabbed. A build log is quite often in my opinion a bad place to grab your attention. That failure at the end will grab my attention just fine. There are times when I might like a colourised log... But more often I prefer to be able to just change the logging levels, or use the terminal's find feature On Friday, 7 December 2012, Gary Gregory wrote: Do you still watch TV in black and white? ;) On Fri, Dec 7, 2012 at 4:28 PM, Jesse McConnell jesse.mcconn...@gmail.com javascript:;wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem -- E-Mail: garydgreg...@gmail.com javascript:; | ggreg...@apache.org javascript:; JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action:
