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: [VOTE] Maven 3.1.0
Mirko; Most of the time the core IT's fail, it seems to be related to stuff in your local settings.xml. Maybe try to just rename it and see how that works. Sometimes the artifact resolution gets stuck less core-it-suite/target/test-classes/mng-5135/log.txt will show you what happened to the build of mng-5135 Theyt are a bit moody at times. Kristian 2012/12/7 Mirko Friedenhagen mfriedenha...@gmail.com: Hello Kristian, I ran d2fc26066b3e5ceb7912b69ce360fa75a8d9a2bb of the maven-integration-testing project using the profiles and: a) did not see a big difference in runtime (mvn304 ~ 9:50, mvn310 ~10:29) b) had failing tests with 310 *and* 304. Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04 05:03:32+0100) Java version: 1.7.0_09, vendor: Oracle Corporation OS name: mac os x, version: 10.8.2, arch: x86_64, family: mac Regards Mirko On Tue, Dec 4, 2012 at 6:52 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - 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
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: [VOTE] Maven 3.1.0
On Friday, 7 December 2012, Anders Hammar wrote: I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. +1 Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. /Anders Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins
Re: [VOTE] Maven 3.1.0
On 07.12.2012 07:25, Anders Hammar wrote: *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. Very nicely put. /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: [VOTE] Maven 3.1.0
basically all stuff which integrates maven does *funky logging stuff*... - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 7:25 AM Subject: Re: [VOTE] Maven 3.1.0 I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. /Anders Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different
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 complexity. The next step I could see is building a fresh classloader up from scratch within the plugin. That *should* work as long as we load a fresh set of slf4j-api classes (ceki?) then we are initialising slf4j a second time in the fresh classloader and we can do as we need. Again complex though one could argue less complex than the RMI route. Plugin developers following this route will have to watch out for the dreaded CCE but at least you are not having to deal with object serialisation and RMI 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 Note that each proposal above retains the option for plugin developers to use the previous proposal. My vote is that we need to provide a utility library that makes the first and second proposals facile for plugin developers and we should probably enable the third option also. The correct respecting of tool chains support requires plugin developers to follow the first route if a tool chain JVM is applied to their plugin and to use the second when no tool chain JVM is in play... At least for the jetty:run and tomcat:run style plugins. For the sonar style plugins, and my gut says the vast majority of these use cases the most they will need is the third proposal. Without seeing a maven-fork-utils api I cannot say that we don't need the third proposal, so I am forced to conclude that we should support it... IOW I think we need a metadata flag. -Stephen On Friday, 7 December 2012, Mark Struberg wrote: basically all stuff which integrates maven does *funky logging stuff*... - Original Message - From: Anders Hammar and...@hammar.net javascript:; To: Maven Developers List dev@maven.apache.org javascript:; Cc: Sent: Friday, December 7, 2012 7:25 AM Subject: Re: [VOTE] Maven 3.1.0 I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. /Anders Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging
Re: [VOTE] Maven 3.1.0
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 complexity. The next step I could see is building a fresh classloader up from scratch within the plugin. That *should* work as long as we load a fresh set of slf4j-api classes (ceki?) then we are initialising slf4j a second time in the fresh classloader and we can do as we need. Again complex though one could argue less complex than the RMI route. Plugin developers following this route will have to watch out for the dreaded CCE but at least you are not having to deal with object serialisation and RMI 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 Note that each proposal above retains the option for plugin developers to use the previous proposal. My vote is that we need to provide a utility library that makes the first and second proposals facile for plugin developers and we should probably enable the third option also. The correct respecting of tool chains support requires plugin developers to follow the first route if a tool chain JVM is applied to their plugin and to use the second when no tool chain JVM is in play... At least for the jetty:run and tomcat:run style plugins. For the sonar style plugins, and my gut says the vast majority of these use cases the most they will need is the third proposal. Without seeing a maven-fork-utils api I cannot say that we don't need the third proposal, so I am forced to conclude that we should support it... IOW I think we need a metadata flag. -Stephen On Friday, 7 December 2012, Mark Struberg wrote: basically all stuff which integrates maven does *funky logging stuff*... - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 7:25 AM Subject: Re: [VOTE] Maven 3.1.0 I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing
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 complexity. The next step I could see is building a fresh classloader up from scratch within the plugin. That *should* work as long as we load a fresh set of slf4j-api classes (ceki?) then we are initialising slf4j a second time in the fresh classloader and we can do as we need. Again complex though one could argue less complex than the RMI route. Plugin developers following this route will have to watch out for the dreaded CCE but at least you are not having to deal with object serialisation and RMI 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 Note that each proposal above retains the option for plugin developers to use the previous proposal. My vote is that we need to provide a utility library that makes the first and second proposals facile for plugin developers and we should probably enable the third option also. The correct respecting of tool chains support requires plugin developers to follow the first route if a tool chain JVM is applied to their plugin and to use the second when no tool chain JVM is in play... At least for the jetty:run and tomcat:run style plugins. For the sonar style plugins, and my gut says the vast majority of these use cases the most they will need is the third proposal. Without seeing a maven-fork-utils api I cannot say that we don't need the third proposal, so I am forced to conclude that we should support it... IOW I think we need a metadata flag. -Stephen On Friday, 7 December 2012, Mark Struberg wrote: basically all stuff which integrates maven does *funky logging stuff*... - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 7:25 AM Subject: Re: [VOTE] Maven 3.1.0 I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants
Re: [VOTE] Maven 3.1.0
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 complexity. The next step I could see is building a fresh classloader up from scratch within the plugin. That *should* work as long as we load a fresh set of slf4j-api classes (ceki?) then we are initialising slf4j a second time in the fresh classloader and we can do as we need. Again complex though one could argue less complex than the RMI route. Plugin developers following this route will have to watch out for the dreaded CCE but at least you are not having to deal with object serialisation and RMI 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 Note that each proposal above retains the option for plugin developers to use the previous proposal. My vote is that we need to provide a utility library that makes the first and second proposals facile for plugin developers and we should probably enable the third option also. The correct respecting of tool chains support requires plugin developers to follow the first route if a tool chain JVM is applied to their plugin and to use the second when no tool chain JVM is in play... At least for the jetty:run and tomcat:run style plugins. For the sonar style plugins, and my gut says the vast majority of these use cases the most they will need is the third proposal. Without seeing a maven-fork-utils api I cannot say that we
Re: [VOTE] Maven 3.1.0
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 complexity. The next step I could see is building a fresh classloader up from scratch within the plugin. That *should* work as long as we load a fresh set of slf4j-api classes (ceki?) then we are initialising slf4j a second time in the fresh classloader and we can do as we need. Again complex though one could argue less complex than the RMI route. Plugin developers following this route will have to watch out for the dreaded CCE but at least you are not having to deal with object serialisation and RMI 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 Note that each proposal above retains the option for plugin developers to use the previous proposal. My vote is that we need to provide a utility library that makes the first and second proposals facile for plugin developers and we should probably enable the third option also. The correct respecting of tool chains support requires plugin developers to follow the first route if a tool chain JVM is applied to their plugin and to use the second when no tool chain JVM is in play
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 complexity. The next step I could see is building a fresh classloader up from scratch within the plugin. That *should* work as long as we load a fresh set of slf4j-api classes (ceki?) then we are initialising slf4j a second time in the fresh classloader and we can do as we need. Again complex though one could argue less complex than the RMI route. Plugin developers following this route will have to watch out for the dreaded CCE but at least you are not having to deal with object serialisation and RMI 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 Note that each proposal above retains the option for plugin developers to use the previous proposal. My vote is that we need to provide a utility library that makes the first and second proposals facile for plugin developers and we should probably
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
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: [VOTE] Maven 3.1.0
On 07.12.2012 02:34, Jason van Zyl wrote: One benefit is that it would hopefully fix the Sonar problem. But I'm not sure what the exact behaviour of SLF4J is. Even if a plugin blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar case, I think SLF4J is already loaded. Ceki might want to comment on how that works. If two SLF4J systems can run in the same JVM it may work. For the non-SLF4J case it's not using SLF4J, obviously, so there is no need to block it. SLF4J uses an extremely simple/primitive binding (aka plugin) mechanism. When the LoggerFactory class is loaded into memory by a given class loader, the first call to the getILoggerFactory() will perform initialization. The getILoggerFactory() method is called by the getLogger(String) method. Thus, if LoggerFactory class is loaded into memory N times but various class loaders, then LoggerFactory class will be initialized N times, under the very likely assumption that the getLogger() method is called at least once for each LoggerFactory instance. HTH, -- 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: [VOTE] Maven 3.1.0
So, it sounds to me like this VOTE is withdrawn, since the RM thinks that there's a respin needed. It would be nice to see a formal email communicating this. On Fri, Dec 7, 2012 at 12:41 PM, ceki c...@qos.ch wrote: On 07.12.2012 02:34, Jason van Zyl wrote: One benefit is that it would hopefully fix the Sonar problem. But I'm not sure what the exact behaviour of SLF4J is. Even if a plugin blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar case, I think SLF4J is already loaded. Ceki might want to comment on how that works. If two SLF4J systems can run in the same JVM it may work. For the non-SLF4J case it's not using SLF4J, obviously, so there is no need to block it. SLF4J uses an extremely simple/primitive binding (aka plugin) mechanism. When the LoggerFactory class is loaded into memory by a given class loader, the first call to the getILoggerFactory() will perform initialization. The getILoggerFactory() method is called by the getLogger(String) method. Thus, if LoggerFactory class is loaded into memory N times but various class loaders, then LoggerFactory class will be initialized N times, under the very likely assumption that the getLogger() method is called at least once for each LoggerFactory instance. HTH, -- Ceki 65% of statistics are made up on the spot - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [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 dev
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
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
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: [VOTE] Maven 3.1.0
Hello Kristian, I ran d2fc26066b3e5ceb7912b69ce360fa75a8d9a2bb of the maven-integration-testing project using the profiles and: a) did not see a big difference in runtime (mvn304 ~ 9:50, mvn310 ~10:29) b) had failing tests with 310 *and* 304. Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04 05:03:32+0100) Java version: 1.7.0_09, vendor: Oracle Corporation OS name: mac os x, version: 10.8.2, arch: x86_64, family: mac Regards Mirko On Tue, Dec 4, 2012 at 6:52 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - 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
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:
Re: [VOTE] Maven 3.1.0
I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me is this: Allow a plugin's metadata to say: 'please leave slf4j isolated here'. Such a plugin could only log to the Maven log through the Mojo log API. That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not trying to derail any 3.1.0 trains here, just thinking ahead. A logging framework is a tool for collecting and distributing information. When someone plugs 'thing X' into Maven, I don't think that it follows, necessarily, that their application of a logging framework necessarily aligns with ours. We are logging 'the build' -- they are logging 'whatever it is that they are doing'. They may log thousands of messages at 'INFO' that are only interesting to some program that digests them, like Apache Flume. That's going to make an awfully hard-to-read console. If we stick to your view, their only option is to mess with the
Re: [VOTE] Maven 3.1.0
On Dec 6, 2012, at 4:34 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. I sent a mail a while back with how the internals but here are the things you should know: - We export the SLF4J API currently, and we do not export the implementation - The user gets the implementation used by the core through Mojo.getLog(), or by injecting an SLF4J logger - SLF4J once initialized cannot change the implementation so there isn't going to be any deciding by the user to use something else, it's not possible after initialization If you want to try and block the SLF4J API then you'll have to dynamically change what packages get imported into the plugin realm. The ClassRealm manager already gets injected into the plugin manager and you could look at the annotation and alter the the realm created accordingly in DefaultMavenPluginManager.calcImports(). Is this a good idea. I don't really think so but give it a whirl. It means that the logging for the plugin won't be integrated so if someone uses the -l option and the rest of the input goes once place and some plugins go to another. I also don't know what other side effects so I think it would be wise to see what actually happens. One benefit is that it would hopefully fix the Sonar problem. But I'm not sure what the exact behaviour of SLF4J is. Even if a plugin blocked SLF4J entirely to use their own SLF4J setup, like in the Sonar case, I think SLF4J is already loaded. Ceki might want to comment on how that works. If two SLF4J systems can run in the same JVM it may work. For the non-SLF4J case it's not using SLF4J, obviously, so there is no need to block it. So if the desire is to allow for a plugin to do its own SLF4J thing you'll want to investigate if it's possible. If it's not then I don't think anything needs to change from how it currently is. If you can make Sonar work, it's worth it the effort. Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that
Re: [VOTE] Maven 3.1.0
I'm interested to help working on adding a metadata to enable slf4j visibility from a plugin: by default, slf4j is not visible, plugins are expected to use plugin-api's Log. But if the plugin wants to use core's slf4j, he would be able to add an annotation in the goal requiring shared core slf4j, then the plugin descriptor would enable slf4j api import from core. *If* we go this path, I think the default should be the other way around. I.e., the default would be to use core's slf4j and it's impl. So the plugin developer needs to do an active choice to go outside Maven's logging. Sure, this could imply problems with existing plugins doing funky logging stuff (like the Sonar plugin), but I don't really see a problem with those plugins having to release a new version. I think it's more important that we get good defaults than trying to make every existing plugin work as they are implemented right now. /Anders Stephen: is this what you have in mind? Regards, Hervé Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me is this: Allow a plugin's metadata to say: 'please leave slf4j isolated here'. Such a plugin could only log to the Maven log through the Mojo log API. That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not
Re: [VOTE] Maven 3.1.0
Minor problem, but I just noticed that wagon-http-2.3-shaded.jar and wagon-provider-api-2.3.jar include what looks like test-related files inside them. -- Regards, Igor On 12-12-03 11:10 PM, Jason van Zyl wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
There is something wrong with logging in embedded mode; when runnin surefire tests with verifier I am no longer able to pick up log output from the running maven process: 2012/12/4 Anders Hammar and...@hammar.net: Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
To reproduce: https://git-wip-us.apache.org/repos/asf/maven-surefire.git cd maven-surefire mvn -DskipTests install cd surefire-integration-tests # ready to rock mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # works less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # Shows log content mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # fails less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # empty file This would seem to be the Embedded3xLauncher in verifier that does not work with 3.1 I assume this might be an issue for other scenarios too Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: There is something wrong with logging in embedded mode; when runnin surefire tests with verifier I am no longer able to pick up log output from the running maven process: 2012/12/4 Anders Hammar and...@hammar.net: Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
+1 non binding so far from my own tests. I suspect Kristian's comment is a -1 tho... Jason van Zyl 4 December 2012 5:10 PM Hi,Here is a link to Jira with 42 issues resolved:https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967Staging repo:https://repository.apache.org/content/repositories/maven-110/The distributable binaries and sources for testing can be found here:https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/Specifically the zip, tarball, and source archives can be found here:https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.ziphttps://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gzhttps://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.ziphttps://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gzStaging site:http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0The documentation specifically for this release pertains to JSR330 and SLF4J-based logging:http://maven.apache.org/maven-jsr330.htmlhttp://maven.apache.org/maven-logging.htmlVote open for 72 hours.[ ] +1[ ] +0[ ] -1Thanks,Jason--Jason van ZylFounder CTO, SonatypeFounder, Apache Mavenhttp://twitter.com/jvanzyl-People develop abstractions by generalizing from concrete examples.Every attempt to determine the correct abstraction on paper withoutactually developing a running system is doomed to failure. No oneis that smart. A framework is a resuable design, so you develop it bylooking at the things it is supposed to be a design of. The more examplesyou look at, the more general your framework will be.-- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks -To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgFor additional commands, e-mail: dev-h...@maven.apache.org-To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgFor additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On Mon, 3 Dec 2012 20:10:41 -0800 Jason van Zyl ja...@tesla.io wrote: When displaying mvn -version I got : Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04 05:03:32+0100) Maven home: /opt/maven I don't understand the revision, Any clue about it ? thanks, tony. Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
When displaying mvn -version I got : Apache Maven 3.1.0 (rNON-CANONICAL_2012-12-03_20-03_jvanzyl; 2012-12-04 05:03:32+0100) Maven home: /opt/maven I don't understand the revision, Any clue about it ? MNG-5402 Working on it. Not a show stopper though in my opinion. /Anders thanks, tony. Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Greetings, On Mon, Dec 3, 2012 at 11:10 PM, Jason van Zyl ja...@tesla.io wrote: The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Created https://jira.codehaus.org/browse/MNG-5403 Continuing to test. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Please do not update the site plugin to 3.2. See http://jira.codehaus.org/browse/MSITE-665. -- Christian Am 12/04/12 05:10, schrieb Jason van Zyl: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
I believe this is the verifier that changed. The embedded tests don't work in general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is not captured to a file which is what causes the test failures. For the tests that are looking specifically for things in the log.txt. On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: To reproduce: https://git-wip-us.apache.org/repos/asf/maven-surefire.git cd maven-surefire mvn -DskipTests install cd surefire-integration-tests # ready to rock mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # works less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # Shows log content mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # fails less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # empty file This would seem to be the Embedded3xLauncher in verifier that does not work with 3.1 I assume this might be an issue for other scenarios too Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: There is something wrong with logging in embedded mode; when runnin surefire tests with verifier I am no longer able to pick up log output from the running maven process: 2012/12/4 Anders Hammar and...@hammar.net: Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: [VOTE] Maven 3.1.0
The failing test in question keeps the verifier at a fixed 1.3 version. But with 3.0.4 it is fully capable of producing the log.txt file in embedded mode. The only thing that changes in the supplied demonstration is the maven version. Embedded tests work *fine* in general but I think a lot of verifier tests rely on asserting things in the log. Hence a lot of them dont work when the log.txt goes missing. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: I believe this is the verifier that changed. The embedded tests don't work in general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is not captured to a file which is what causes the test failures. For the tests that are looking specifically for things in the log.txt. On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: To reproduce: https://git-wip-us.apache.org/repos/asf/maven-surefire.git cd maven-surefire mvn -DskipTests install cd surefire-integration-tests # ready to rock mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # works less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # Shows log content mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # fails less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # empty file This would seem to be the Embedded3xLauncher in verifier that does not work with 3.1 I assume this might be an issue for other scenarios too Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: There is something wrong with logging in embedded mode; when runnin surefire tests with verifier I am no longer able to pick up log output from the running maven process: 2012/12/4 Anders Hammar and...@hammar.net: Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties,
Re: [VOTE] Maven 3.1.0
If I build m3 core at 22df629f9707e46cfabddd3d657757701bd64a76 the supplied testcase works. When I do git reset --hard 25669cfe131e19f152c87c1b250ffec0b30f8d26 to move 2 commits later in history, it stops working. git log 22df629f9707e46cfabddd3d657757701bd64a76..25669cfe131e19f152c87c1b250ffec0b30f8d26 Shows that the introduction of slf4j broke this. As for the core it's in embedded mode, I have never really had much success with those. But this break will most definitely torpedo the core its in embedded mode right out of the water. Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: The failing test in question keeps the verifier at a fixed 1.3 version. But with 3.0.4 it is fully capable of producing the log.txt file in embedded mode. The only thing that changes in the supplied demonstration is the maven version. Embedded tests work *fine* in general but I think a lot of verifier tests rely on asserting things in the log. Hence a lot of them dont work when the log.txt goes missing. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: I believe this is the verifier that changed. The embedded tests don't work in general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is not captured to a file which is what causes the test failures. For the tests that are looking specifically for things in the log.txt. On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: To reproduce: https://git-wip-us.apache.org/repos/asf/maven-surefire.git cd maven-surefire mvn -DskipTests install cd surefire-integration-tests # ready to rock mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # works less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # Shows log content mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # fails less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # empty file This would seem to be the Embedded3xLauncher in verifier that does not work with 3.1 I assume this might be an issue for other scenarios too Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: There is something wrong with logging in embedded mode; when runnin surefire tests with verifier I am no longer able to pick up log output from the running maven process: 2012/12/4 Anders Hammar and...@hammar.net: Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
I'll do the same for the core ITs when I ran them against 3.0.3, 3.0.4 and master they all failed in embedded mode with the same problem. So your surefire ITs fork once using the embedder and use the special method in MavenCli that has this signature: public int doMain( String[] args, String workingDirectory, PrintStream stdout, PrintStream stderr ) If so then we're looking at the same problem. On Dec 4, 2012, at 8:54 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: If I build m3 core at 22df629f9707e46cfabddd3d657757701bd64a76 the supplied testcase works. When I do git reset --hard 25669cfe131e19f152c87c1b250ffec0b30f8d26 to move 2 commits later in history, it stops working. git log 22df629f9707e46cfabddd3d657757701bd64a76..25669cfe131e19f152c87c1b250ffec0b30f8d26 Shows that the introduction of slf4j broke this. As for the core it's in embedded mode, I have never really had much success with those. But this break will most definitely torpedo the core its in embedded mode right out of the water. Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: The failing test in question keeps the verifier at a fixed 1.3 version. But with 3.0.4 it is fully capable of producing the log.txt file in embedded mode. The only thing that changes in the supplied demonstration is the maven version. Embedded tests work *fine* in general but I think a lot of verifier tests rely on asserting things in the log. Hence a lot of them dont work when the log.txt goes missing. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: I believe this is the verifier that changed. The embedded tests don't work in general and I tried with Maven 3.0.3 and 3.0.4 andific the log output is not captured to a file which is what causes the test failures. For the tests that are looking specifically for things in the log.txt. On Dec 4, 2012, at 2:38 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: To reproduce: https://git-wip-us.apache.org/repos/asf/maven-surefire.git cd maven-surefire mvn -DskipTests install cd surefire-integration-tests # ready to rock mvn304 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # works less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # Shows log content mvn31 -Dit.test=IncludesExcludesFromFileIT -Dverifier.forkMode=auto clean install # fails less target/IncludesExcludesFromFileIT/includes-excludes-from-file/log.txt # empty file This would seem to be the Embedded3xLauncher in verifier that does not work with 3.1 I assume this might be an issue for other scenarios too Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: There is something wrong with logging in embedded mode; when runnin surefire tests with verifier I am no longer able to pick up log output from the running maven process: 2012/12/4 Anders Hammar and...@hammar.net: Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable
Re: [VOTE] Maven 3.1.0
The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Our build server appears out, and I wanted to get off my machine so I spun up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears to be the problem. Obviously this affects people who embed, but won't affect CLI users. The major use case is m2e and it already uses SLF4J with logback so I don't see any issues there, but if others are concerned I'll track it down. On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - 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 - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: [VOTE] Maven 3.1.0
The severity of the issue is less 2012/12/4 Jason van Zyl ja...@tesla.io: Our build server appears out, and I wanted to get off my machine so I spun up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears to be the problem. Obviously this affects people who embed, but won't affect CLI users. The major use case is m2e and it already uses SLF4J with logback so I don't see any issues there, but if others are concerned I'll track it down. On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - 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 - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Obviously if it doesnt affect m2e (and this is known ?) its less of a problem. In that case it means it'll just be a PITA for those 10-or so projects that use verifier here at asf and any others. I am no fan of releasing a version I wouldn't want to use myself, so I think this needs to be fixed - it's *our* time that will be wasted in the future if we let this through. So changing verifier to use a better approach may come, but I'm not sure it should come for /this/ reason? Is this for some reason a hard issue to fix ? Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: The severity of the issue is less 2012/12/4 Jason van Zyl ja...@tesla.io: Our build server appears out, and I wanted to get off my machine so I spun up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears to be the problem. Obviously this affects people who embed, but won't affect CLI users. The major use case is m2e and it already uses SLF4J with logback so I don't see any issues there, but if others are concerned I'll track it down. On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - 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 - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
I don't think it will be hard to fix, it's just the use of a BOAS, setting stdout/err repeatedly and then using stdout for logging in SLF4J. Just need to track down the interactions and fix it. On Dec 4, 2012, at 11:13 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Obviously if it doesnt affect m2e (and this is known ?) its less of a problem. In that case it means it'll just be a PITA for those 10-or so projects that use verifier here at asf and any others. I am no fan of releasing a version I wouldn't want to use myself, so I think this needs to be fixed - it's *our* time that will be wasted in the future if we let this through. So changing verifier to use a better approach may come, but I'm not sure it should come for /this/ reason? Is this for some reason a hard issue to fix ? Kristian 2012/12/4 Kristian Rosenvold kristian.rosenv...@gmail.com: The severity of the issue is less 2012/12/4 Jason van Zyl ja...@tesla.io: Our build server appears out, and I wanted to get off my machine so I spun up an EC2 instance and it is 3.1.x with SLF4J in embedded mode that appears to be the problem. Obviously this affects people who embed, but won't affect CLI users. The major use case is m2e and it already uses SLF4J with logback so I don't see any issues there, but if others are concerned I'll track it down. On Dec 4, 2012, at 9:52 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The core it's were running against 1.4-SNAPSHOT of the verifier and I had introduced a minor compatibility problem when adding generics which caused them to not compile. That is fixed on verifier trunk now. I just ran the following core it's, and they run lightning fast razor sharp: mvn304 -Pembedded,run-its clean install # success, 5min 11 sec mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76 (2 failing IT's that were fixed in later 3.1 versions - as expected) mvn31 -Pembedded,run-its clean install # At 22df629f9707e46cfabddd3d657757701bd64a76, large amounts of failures for instance mng4829 So the problem was introduced with slf4j; case closed. Kristian 2012/12/4 Jason van Zyl ja...@tesla.io: M - 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 - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - 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 - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: [VOTE] Maven 3.1.0
Has anyone tried 3.1.0 with heavy use of version ranges? I'm noticing my integration tests seem to now be taking a LONG time to resolve deps - about 15 dependency elements all using ranges, of which the repository has something like 100+ versions of each. A thread dump of the process when its just sitting there is below - is Aether just reallly slow here? 1022 ± jstack 7124 ✹ ✭ 2012-12-05 12:22:29 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode): Attach Listener daemon prio=5 tid=0x7fad8e33c800 nid=0x3e0b waiting on condition [0x] java.lang.Thread.State: RUNNABLE Service Thread daemon prio=5 tid=0x7fad8b050800 nid=0x4c03 runnable [0x] java.lang.Thread.State: RUNNABLE C2 CompilerThread1 daemon prio=5 tid=0x7fad8b05 nid=0x4b03 waiting on condition [0x] java.lang.Thread.State: RUNNABLE C2 CompilerThread0 daemon prio=5 tid=0x7fad8b04b000 nid=0x4a03 waiting on condition [0x] java.lang.Thread.State: RUNNABLE Signal Dispatcher daemon prio=5 tid=0x7fad8b044000 nid=0x4903 runnable [0x] java.lang.Thread.State: RUNNABLE Finalizer daemon prio=5 tid=0x7fad8c020800 nid=0x3703 in Object.wait() [0x0001606b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x0001251e0d30 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked 0x0001251e0d30 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177) Reference Handler daemon prio=5 tid=0x7fad8c01f800 nid=0x3603 in Object.wait() [0x0001605af000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x0001251e0dc8 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) - locked 0x0001251e0dc8 (a java.lang.ref.Reference$Lock) main prio=5 tid=0x7fad8c000800 nid=0x1703 runnable [0x00010cae7000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:242) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) - locked 0x000114311100 (a java.io.BufferedInputStream) at org.codehaus.plexus.util.xml.XmlReader.getBOMEncoding(XmlReader.java:635) at org.codehaus.plexus.util.xml.XmlReader.doRawStream(XmlReader.java:459) at org.codehaus.plexus.util.xml.XmlReader.init(XmlReader.java:180) at org.codehaus.plexus.util.xml.XmlReader.init(XmlReader.java:143) at org.codehaus.plexus.util.xml.XmlStreamReader.init(XmlStreamReader.java:86) at org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:104) at org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader.read(MetadataXpp3Reader.java:827) at org.apache.maven.repository.internal.DefaultVersionResolver.readVersions(DefaultVersionResolver.java:330) at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:240) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:250) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:412) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:150) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at
Re: [VOTE] Maven 3.1.0
Did anything change in your build as Aether didn't change between now and the last release. The version of plexus-utils did change, maybe try swapping the version of plexus-utils and see if that helps. On Dec 4, 2012, at 3:24 PM, Mark Derricutt m...@talios.com wrote: Has anyone tried 3.1.0 with heavy use of version ranges? I'm noticing my integration tests seem to now be taking a LONG time to resolve deps - about 15 dependency elements all using ranges, of which the repository has something like 100+ versions of each. A thread dump of the process when its just sitting there is below - is Aether just reallly slow here? 1022 ± jstack 7124 ✹ ✭ 2012-12-05 12:22:29 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode): Attach Listener daemon prio=5 tid=0x7fad8e33c800 nid=0x3e0b waiting on condition [0x] java.lang.Thread.State: RUNNABLE Service Thread daemon prio=5 tid=0x7fad8b050800 nid=0x4c03 runnable [0x] java.lang.Thread.State: RUNNABLE C2 CompilerThread1 daemon prio=5 tid=0x7fad8b05 nid=0x4b03 waiting on condition [0x] java.lang.Thread.State: RUNNABLE C2 CompilerThread0 daemon prio=5 tid=0x7fad8b04b000 nid=0x4a03 waiting on condition [0x] java.lang.Thread.State: RUNNABLE Signal Dispatcher daemon prio=5 tid=0x7fad8b044000 nid=0x4903 runnable [0x] java.lang.Thread.State: RUNNABLE Finalizer daemon prio=5 tid=0x7fad8c020800 nid=0x3703 in Object.wait() [0x0001606b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x0001251e0d30 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked 0x0001251e0d30 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177) Reference Handler daemon prio=5 tid=0x7fad8c01f800 nid=0x3603 in Object.wait() [0x0001605af000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x0001251e0dc8 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) - locked 0x0001251e0dc8 (a java.lang.ref.Reference$Lock) main prio=5 tid=0x7fad8c000800 nid=0x1703 runnable [0x00010cae7000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:242) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) - locked 0x000114311100 (a java.io.BufferedInputStream) at org.codehaus.plexus.util.xml.XmlReader.getBOMEncoding(XmlReader.java:635) at org.codehaus.plexus.util.xml.XmlReader.doRawStream(XmlReader.java:459) at org.codehaus.plexus.util.xml.XmlReader.init(XmlReader.java:180) at org.codehaus.plexus.util.xml.XmlReader.init(XmlReader.java:143) at org.codehaus.plexus.util.xml.XmlStreamReader.init(XmlStreamReader.java:86) at org.codehaus.plexus.util.ReaderFactory.newXmlReader(ReaderFactory.java:104) at org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader.read(MetadataXpp3Reader.java:827) at org.apache.maven.repository.internal.DefaultVersionResolver.readVersions(DefaultVersionResolver.java:330) at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:240) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:250) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:412) at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:308) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:150) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at
Re: [VOTE] Maven 3.1.0
My bad - looks like IntelliJ 12 turns on its new compiler mode by default which runs a separate VM for compilation - with a default heap size of 700mb - my machine found itself dying in a mess of 4gb swap which was messing with things. On a fresh reboot things seem much more like what I expect. Jason van Zyl wrote: Did anything change in your build as Aether didn't change between now and the last release. The version of plexus-utils did change, maybe try swapping the version of plexus-utils and see if that helps. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On 11/28/2012 11:04 AM, Arnaud Héritier wrote: there are only few bug fixes For the affected users, MNG-5312 [1] is pretty serious. [1] https://jira.codehaus.org/browse/MNG-5312 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Maven 3.1.0
Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
Is the site updated? It says it was published Nov 15 and some info doesn't seem to be up-to-date (m-war-p says v2.3 for default lifecycle bindings). /Anders On Tue, Dec 4, 2012 at 5:10 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 42 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-110/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-bin.tar.gz https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.zip https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/apache-maven-3.1.0-src.tar.gz Staging site: http://people.apache.org/~jvanzyl/staged-sites/ref/3.1.0 The documentation specifically for this release pertains to JSR330 and SLF4J-based logging: http://maven.apache.org/maven-jsr330.html http://maven.apache.org/maven-logging.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - 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: [VOTE] Maven 3.1.0
what is complex with say am openjpa enhancer mojo? Still this will break depending what the project configures in it's persistence.xml. Just an idea for now: The safe route might be a plugin-plugin annotatation which tells us 'plugin uses slf4j' in that case it gets exposed, in other cases it doesn't. Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will evaluate it and add slf4j injection support for those plugins. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 10:15 PM Subject: Re: [VOTE] Maven 3.1.0 At the end of the day, either Maven uses a standard logging API inside plugins, or it does not. Using a standard logging API has giant advantages - but it can inconvenience people integrating complex code via plugins. In this thread, there are two approaches to removing that inconvenience: a plugin annotation that changing the logging integration, and use of forking. Both work. I have some sympathy for the view that anything complex enough to care should fork. When people integrate big complex things, it has unpleasant consequences like System.exit() calls. So I'm entirely +1 for the code as it stands, and I see adding an annotation or something to avoid injecting the logging back end as a nice to have. As I wrote before, I'd feel better about the 'stick a fork' in it prescription if we had better reusable forking code. - 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: [VOTE] Maven 3.1.0
Couldn't we use the shading plugin to not expose the original implementation (logback, log4k, whatever ..) but a repackaged one to avoid conflicts with plugins which may bring (intentionally or by error) its own impl ? ? Perhaps my idea is just stupid ... Arnaud On Sat, Dec 1, 2012 at 11:02 AM, Mark Struberg strub...@yahoo.de wrote: what is complex with say am openjpa enhancer mojo? Still this will break depending what the project configures in it's persistence.xml. Just an idea for now: The safe route might be a plugin-plugin annotatation which tells us 'plugin uses slf4j' in that case it gets exposed, in other cases it doesn't. Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will evaluate it and add slf4j injection support for those plugins. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 10:15 PM Subject: Re: [VOTE] Maven 3.1.0 At the end of the day, either Maven uses a standard logging API inside plugins, or it does not. Using a standard logging API has giant advantages - but it can inconvenience people integrating complex code via plugins. In this thread, there are two approaches to removing that inconvenience: a plugin annotation that changing the logging integration, and use of forking. Both work. I have some sympathy for the view that anything complex enough to care should fork. When people integrate big complex things, it has unpleasant consequences like System.exit() calls. So I'm entirely +1 for the code as it stands, and I see adding an annotation or something to avoid injecting the logging back end as a nice to have. As I wrote before, I'd feel better about the 'stick a fork' in it prescription if we had better reusable forking code. - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [VOTE] Maven 3.1.0
In that case the users cannot use plain slf4j APIs and we would not gain anything anyway. This would have the same effect like not exposing the classes in our core realm at all. LieGrue, strub From: Arnaud Héritier aherit...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Saturday, December 1, 2012 11:20 AM Subject: Re: [VOTE] Maven 3.1.0 Couldn't we use the shading plugin to not expose the original implementation (logback, log4k, whatever ..) but a repackaged one to avoid conflicts with plugins which may bring (intentionally or by error) its own impl ? ? Perhaps my idea is just stupid ... Arnaud On Sat, Dec 1, 2012 at 11:02 AM, Mark Struberg strub...@yahoo.de wrote: what is complex with say am openjpa enhancer mojo? Still this will break depending what the project configures in it's persistence.xml. Just an idea for now: The safe route might be a plugin-plugin annotatation which tells us 'plugin uses slf4j' in that case it gets exposed, in other cases it doesn't. Old maven versions will ignore the tag in plugin.xml and mvn-3.1++ will evaluate it and add slf4j injection support for those plugins. LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 10:15 PM Subject: Re: [VOTE] Maven 3.1.0 At the end of the day, either Maven uses a standard logging API inside plugins, or it does not. Using a standard logging API has giant advantages - but it can inconvenience people integrating complex code via plugins. In this thread, there are two approaches to removing that inconvenience: a plugin annotation that changing the logging integration, and use of forking. Both work. I have some sympathy for the view that anything complex enough to care should fork. When people integrate big complex things, it has unpleasant consequences like System.exit() calls. So I'm entirely +1 for the code as it stands, and I see adding an annotation or something to avoid injecting the logging back end as a nice to have. As I wrote before, I'd feel better about the 'stick a fork' in it prescription if we had better reusable forking code. - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me is this: Allow a plugin's metadata to say: 'please leave slf4j isolated here'. Such a plugin could only log to the Maven log through the Mojo log API. That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not trying to derail any 3.1.0 trains here, just thinking ahead. A logging framework is a tool for collecting and distributing information. When someone plugs 'thing X' into Maven, I don't think that it follows, necessarily, that their application of a logging framework necessarily aligns with ours. We are logging 'the build' -- they are logging 'whatever it is that they are doing'. They may log thousands of messages at 'INFO' that are only interesting to some program that digests them, like Apache Flume. That's going to make an awfully hard-to-read console. If we stick to your view, their only option is to mess with the global Maven logging config to reroute their messages, and that's very out of keeping with the whole model of maven plugins as self-contained. I am content to wait for the first JIRA from someone who has this issue, and then advocate for the magic, rather than continue an argument right now. I may be understating the strength of Olivier's (and others') desire to avoid surprising the authors of plugins that call things that call slf4j, though I can see 'surprise' in both directions here in the long run. Given this is 3.1.0 I believe it's more a matter of documenting how plugin should integrate their logging with Maven's SLF4J system. An app server which may integrate all manner of things works. If you want to integrate with me, this is how you need to do it. - 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 - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me is this: Allow a plugin's metadata to say: 'please leave slf4j isolated here'. Such a plugin could only log to the Maven log through the Mojo log API. That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not trying to derail any 3.1.0 trains here, just thinking ahead. A logging framework is a tool for collecting and distributing information. When someone plugs 'thing X' into Maven, I don't think that it follows, necessarily, that their application of a logging framework necessarily aligns with ours. We are logging 'the build' -- they are logging 'whatever it is that they are doing'. They may log thousands of messages at 'INFO' that are only interesting to some program that digests them, like Apache Flume. That's going to make an awfully hard-to-read console. If we stick to your view, their only option is to mess with the global Maven logging config to reroute their messages, and that's very out of keeping with the whole model of maven plugins as self-contained. I am content to wait for the first JIRA from someone who has this issue, and then advocate for the magic, rather than continue an argument right now. I may be understating the strength of Olivier's (and others') desire to avoid surprising the authors of plugins that call things that call slf4j, though I can see 'surprise' in both directions here in the long run. Given this is 3.1.0 I believe it's more a matter of documenting how plugin
Re: [VOTE] Maven 3.1.0
On Fri, Nov 30, 2012 at 7:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. I'd be happier with forking if we had a maven-fork-utils project that allowed any plugin author, easily, to have as many forks at his or her place-setting as we see in, say, surefire. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me is this: Allow a plugin's metadata to say: 'please leave slf4j isolated here'. Such a plugin could only log to the Maven log through the Mojo log API. That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not trying to derail any 3.1.0 trains here, just thinking ahead. A logging framework is a tool for collecting and distributing information. When someone plugs 'thing X' into Maven, I don't think that it follows, necessarily, that their application of a logging framework necessarily aligns with ours. We are logging 'the build' -- they are logging 'whatever it is that they are doing'. They may log thousands of messages at 'INFO' that are only interesting to some program that digests them, like Apache Flume. That's going to make an awfully hard-to-read console. If we stick to your view, their only option is to mess with the global Maven logging config to reroute their messages, and that's very out of keeping with the whole model of maven plugins as self-contained. I am content to wait for the first JIRA from someone who has this issue, and then advocate for the magic, rather than continue an argument right now. I may be
Re: [VOTE] Maven 3.1.0
Hi All, In sonar-core, looking at the Logback class in the org.sonar.core.config package, you can find following lines: import ch.qos.logback.classic.LoggerContext; import org.slf4j.LoggerFactory; ... LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); Sonar is assuming that SLF4J is bound with Logback, not an unreasonable assumption for stand-alone Sonar or for a maven-plugin before Maven started using SLF4J. However, with Maven 3.1, this assumption proves to be incorrect. I would suggest to contact Sonar people so that the code which configures Logback first checks that SLF4J is bound to Logback. If not, the code should not attempt to configure logback. Basically, Sonar should add a few lines of defensive code. My 2c. -- 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: [VOTE] Maven 3.1.0
On Nov 30, 2012, at 4:09 AM, Benson Margulies bimargul...@gmail.com wrote: That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not trying to derail any 3.1.0 trains here, just thinking ahead. These are good discussions and it's important to make sure we try some things because one we let this out it's going to be hard to pull back. If we roll it five more times I don't think that's a problem and I don't mind rolling it again and again. But I shouldn't send email right before going to bed and I should have looked at the realms because we're not exporting the package that contains the SLF4J implementation, we are only exporting the API if you look at the DefaultClassRealmManager. I will try something here locally but after looking again I think plugins will be fine because the Plugin API is exported and therefore users have access to the implementation of SLF4J used in the core without exposing it, and the implementation is also available through injection or using the static LoggerFactory method. I will verify that now. I think the problem with Sonar is misuse of the API and Simon agrees with me but I don't want to break Sonar users. A logging framework is a tool for collecting and distributing information. When someone plugs 'thing X' into Maven, I don't think that it follows, necessarily, that their application of a logging framework necessarily aligns with ours. We are logging 'the build' -- they are logging 'whatever it is that they are doing'. They may log thousands of messages at 'INFO' that are only interesting to some program that digests them, like Apache Flume. That's going to make an awfully hard-to-read console. If we stick to your view, their only option is to mess with the global Maven logging config to reroute their messages, and that's very out of keeping with the whole model of maven plugins as self-contained. If you are running something like Flume that also has the possibly of making your CI server fall over I would not run that in-process. If they fork and run it in isolation I believe they will have not have to contend with what we've setup for logging. I am content to wait for the first JIRA from someone who has this issue, and then advocate for the magic, rather than continue an argument right now. I think it's setup now the way we want, we just happen to have an unfortunate use of the API in Sonar but I think we're going to have to deal with that. If 3.1.0 comes out and Sonar doesn't work I don't think that's acceptable even though it's not really our fault. I may be understating the strength of Olivier's (and others') desire to avoid surprising the authors of plugins that call things that call slf4j, though I can see 'surprise' in both directions here in the long run. Given this is 3.1.0 I believe it's more a matter of documenting how plugin should integrate their logging with Maven's SLF4J system. An app server which may integrate all manner of things works. If you want to integrate with me, this is how you need to do it. - 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 - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - 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 man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Re: [VOTE] Maven 3.1.0
I agree that the Sonar plugin is bogus and unrelated to the discussion at hand, and I accept your explanation that we're not, in fact, going to derail legitimate 'self-contained' plugins. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me is this: Allow a plugin's metadata to say: 'please leave slf4j isolated here'. Such a plugin could only log to the Maven log through the Mojo log API. That's the magic I would like to avoid. Anything is possible but I would prefer how a plugin author should integrate with our SLF4J logging. Here's the crux of the disagreement. To be clear, I'm not trying to derail any 3.1.0 trains here, just thinking ahead. A logging framework is a tool for collecting and distributing information. When someone plugs 'thing X' into Maven, I don't think that it follows, necessarily, that their application of a logging framework necessarily aligns with ours. We are logging 'the build' -- they are logging 'whatever it is that they are doing'. They may log thousands of messages at 'INFO' that are only interesting to some program that digests them, like Apache Flume. That's going to make an awfully hard-to-read console. If we stick to your view, their only option is to mess with the global Maven logging config to reroute their messages, and that's very out of keeping with the whole model of maven plugins as self-contained. I am content to wait for the first JIRA from someone who has this issue, and then advocate for the magic, rather than continue an argument right
Re: [VOTE] Maven 3.1.0
What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 Currently 3.0.4 does not provide either the api or an impl, so I need both as a dependency.., I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log and part of the plugin jar (because it makes most sense to scope it there) What happens when that runs on 3.1.0? Oh and in my custom slf4j impl I actuall knock all the logging levels down by 1, because this tool I am using is too verbose and what it spouts at INFO is really DEBUG... So bypassing my impl would be a bad thing for users On Friday, 30 November 2012, Jason van Zyl wrote: For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than the core. However, another possibility that occurs to me
Re: [VOTE] Maven 3.1.0
On Nov 30, 2012, at 11:15 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 If it's in 3.0.4 then you are using Mojo.getLog(), which is probably the ideal case, and this will work without change in 3.1.0. Currently 3.0.4 does not provide either the api or an impl, so I need both as a dependency.., If you want to use SLF4J in 3.0.4 where is doesn't exist then yes. But I would just stick with Mojo.getLog(). I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log and part of the plugin jar (because it makes most sense to scope it there) What happens when that runs on 3.1.0? Can you give me a little plugin that demonstrates? I'm building a bunch of sample plugins now doing all the weird things we can think of. Oh and in my custom slf4j impl I actuall knock all the logging levels down by 1, because this tool I am using is too verbose and what it spouts at INFO is really DEBUG... So bypassing my impl would be a bad thing for users You can control that with the configuration included, we have done that with Sisu to quiet it down. After chatting with Ceki I learned that it's not possible once SLF4J starts up to change the implementation. I don't think this is really a problem, the host system picks the implementation and that's what's used. So I think this is becoming rather clear that we should probably just pick the best implementation we can and go with it. On Friday, 30 November 2012, Jason van Zyl wrote: For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are
Re: [VOTE] Maven 3.1.0
That's all broken by design as already predicted 2 months ago. Imo the only portable way is to NOT expose slf4j in the Core Realm at all. The other way would be to introduce a plugin-plugin configuration which says logging yes/no. LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 8:15 PM Subject: Re: [VOTE] Maven 3.1.0 What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 Currently 3.0.4 does not provide either the api or an impl, so I need both as a dependency.., I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log and part of the plugin jar (because it makes most sense to scope it there) What happens when that runs on 3.1.0? Oh and in my custom slf4j impl I actuall knock all the logging levels down by 1, because this tool I am using is too verbose and what it spouts at INFO is really DEBUG... So bypassing my impl would be a bad thing for users On Friday, 30 November 2012, Jason van Zyl wrote: For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven and you're using SLF4J I think you should defer to what Maven has setup. As things are, that could be done only, I think, by using shade to rename a copy of slf4j for the guts of the plugin. We have the capability in the core, that is OSGi-esque, that allows us to block classes from being accessible to plugins. We can block/allow any classes we choose: we can effectively make anything invisible to plugins if we choose. This capability was added to Classworlds some time ago. If I were less sleep-deprived, I might be able to put forth an idea about how an enhancement to slf4j could allow everyone to be happy here, but I don't see a way to make everyone happy as things are. My personal view is that 'giant subsystem' plugins are rarities at most, and the attraction of saying 'the Maven logging API *is* slf4j' outweighs for me the problems. I think everyone agrees there, it's really now a matter would we let plugins pick and use a different implementation than
Re: [VOTE] Maven 3.1.0
On Nov 30, 2012, at 11:55 AM, Mark Struberg strub...@yahoo.de wrote: That's all broken by design as already predicted 2 months ago. It is not broken by design and you're not being helpful. Retreating into trying to implement all this ourselves is not a solution. Try it Mark, implement your system and ignore everything that's been done and I predict you're going to end up in the exact same place because integrating many systems in a common way is hard. This is the nitty gritty of integration, it's ugly to make it work but that's always the way it is. We're still going to end up in the same place and it's not impossible to change the way the binding works in SLF4J and it's been requested, but the entire world of use of SLF4J doesn't seem to see it as a problem. Imo the only portable way is to NOT expose slf4j in the Core Realm at all. The other way would be to introduce a plugin-plugin configuration which says logging yes/no. I don't believe it's valid to just let everyone do whatever they want. The only problem we've seen thus far is a problem where it's clearly a misuse of the SLF4J API. I still argue that the implementation used by the core can be used by plugins and letting arbitrary implementations and arbitrary manipulation of the logging system isn't really that valuable in compared to having a a consistent pattern that's used by so many others. LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 8:15 PM Subject: Re: [VOTE] Maven 3.1.0 What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 Currently 3.0.4 does not provide either the api or an impl, so I need both as a dependency.., I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log and part of the plugin jar (because it makes most sense to scope it there) What happens when that runs on 3.1.0? Oh and in my custom slf4j impl I actuall knock all the logging levels down by 1, because this tool I am using is too verbose and what it spouts at INFO is really DEBUG... So bypassing my impl would be a bad thing for users On Friday, 30 November 2012, Jason van Zyl wrote: For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl ja...@tesla.io wrote: On Nov 29, 2012, at 5:56 PM, Benson Margulies bimargul...@gmail.com wrote: Currently I'm of the mind that if you make a Maven plugin that uses something that employs SLF4J then the best practice is to only use the API and let the host choose the implementation, in our case Maven. Relying on SLF4J implementation specifics in a system you're embedded in is not good e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want to your own logging thing while being invoked by Maven then you fork the JVM and then you can do whatever you want. I read Olivier's point to be this: it would be cool if we could think of a way for a plugin to use the slf4j API and remain independent of the logging workings of the maven core. I think you mean remain independent of the SLF4J implemented used by Maven's core. Sure, but my counter line of argument would be is that really valid? If you are running in the context of Maven
Re: [VOTE] Maven 3.1.0
I don't believe it's valid to just let everyone do whatever they want. Well, I think this is the fundamental point we disagree on. Maven is not only a build system but also a container which runs user specific stuff. And a container should try to isolate as much internal details from it's users as he can. So yes, imo we should let everyone do whatever they want! By forcing some specific logging mechanism on any users we will heavily restrict plugin programmers. And sometimes even the plugin programmers cannot change anything because the are only 'users' of the library the plugin uses. I personally believe we will introduce quite some backward incompatibility. Plugins which didn't use slf4j will not see any difference. And plugins and frameworks which used slf4j will loose control over their logging. I'd be happy to be proved wrong... LieGrue, strub From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, November 30, 2012 9:08 PM Subject: Re: [VOTE] Maven 3.1.0 On Nov 30, 2012, at 11:55 AM, Mark Struberg strub...@yahoo.de wrote: That's all broken by design as already predicted 2 months ago. It is not broken by design and you're not being helpful. Retreating into trying to implement all this ourselves is not a solution. Try it Mark, implement your system and ignore everything that's been done and I predict you're going to end up in the exact same place because integrating many systems in a common way is hard. This is the nitty gritty of integration, it's ugly to make it work but that's always the way it is. We're still going to end up in the same place and it's not impossible to change the way the binding works in SLF4J and it's been requested, but the entire world of use of SLF4J doesn't seem to see it as a problem. Imo the only portable way is to NOT expose slf4j in the Core Realm at all. The other way would be to introduce a plugin-plugin configuration which says logging yes/no. I don't believe it's valid to just let everyone do whatever they want. The only problem we've seen thus far is a problem where it's clearly a misuse of the SLF4J API. I still argue that the implementation used by the core can be used by plugins and letting arbitrary implementations and arbitrary manipulation of the logging system isn't really that valuable in compared to having a a consistent pattern that's used by so many others. LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 8:15 PM Subject: Re: [VOTE] Maven 3.1.0 What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 Currently 3.0.4 does not provide either the api or an impl, so I need both as a dependency.., I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log and part of the plugin jar (because it makes most sense to scope it there) What happens when that runs on 3.1.0? Oh and in my custom slf4j impl I actuall knock all the logging levels down by 1, because this tool I am using is too verbose and what it spouts at INFO is really DEBUG... So bypassing my impl would be a bad thing for users On Friday, 30 November 2012, Jason van Zyl wrote: For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting to shunt the logs from the build tool (or more likely app server) to a separate file, or tweak the level of logs higher than INFO for that app server/mojo execution as it will just drown the user. In the first use case, Jason's point is correct. They shouldn't need to bundle a logging implementation any more. The second case, Jason is arguing that they shouldn't be using the Maven JVM for running that tool, they should be running it in a forked JVM and then they can configure the logging in that JVM. I disagree. Forking a JVM for every little build tool just to control its logging is going to kill the build time. My preference is for a metadata flag that says: Oy! I know what I'm doing with logging, so don't pass logging on to me. While it feels like a special case the truth is logging is always, and always will be, a special case! -Stephen On 30 November 2012 12:09, Benson Margulies bimargul...@gmail.com wrote: On Thu, Nov 29
Re: [VOTE] Maven 3.1.0
On Nov 30, 2012, at 12:33 PM, Mark Struberg strub...@yahoo.de wrote: I don't believe it's valid to just let everyone do whatever they want. Well, I think this is the fundamental point we disagree on. Maven is not only a build system No, but the only other one people are contemplating using, Gradle, also uses SLF4J. but also a container which runs user specific stuff. And a container should try to isolate as much internal details from it's users as he can. So yes, imo we should let everyone do whatever they want! By forcing some specific logging mechanism on any users we will heavily restrict plugin programmers. And sometimes even the plugin programmers cannot change anything because the are only 'users' of the library the plugin uses. Then systems change to integrate and over time that will happen. The only issue is if they use SLF4J as the API and assume an implementation, otherwise their own custom logging stuff will kick in. I don't think misusing SLF4J is our problem really. Unfortunately Sonar will get dinged but dynamically flipping implementations isn't something SLF4J does and really it's not something any logging framework has really done is it? I personally believe we will introduce quite some backward incompatibility. Plugins which didn't use slf4j will not see any difference. And plugins and frameworks which used slf4j will loose control over their logging. I'd be happy to be proved wrong... We are discussing and implementing different solutions so give your theory a try. No one here is in a dire rush here but I think we have something that's viable. There will always be exceptions but for the most part I believe what we have will work. LieGrue, strub From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, November 30, 2012 9:08 PM Subject: Re: [VOTE] Maven 3.1.0 On Nov 30, 2012, at 11:55 AM, Mark Struberg strub...@yahoo.de wrote: That's all broken by design as already predicted 2 months ago. It is not broken by design and you're not being helpful. Retreating into trying to implement all this ourselves is not a solution. Try it Mark, implement your system and ignore everything that's been done and I predict you're going to end up in the exact same place because integrating many systems in a common way is hard. This is the nitty gritty of integration, it's ugly to make it work but that's always the way it is. We're still going to end up in the same place and it's not impossible to change the way the binding works in SLF4J and it's been requested, but the entire world of use of SLF4J doesn't seem to see it as a problem. Imo the only portable way is to NOT expose slf4j in the Core Realm at all. The other way would be to introduce a plugin-plugin configuration which says logging yes/no. I don't believe it's valid to just let everyone do whatever they want. The only problem we've seen thus far is a problem where it's clearly a misuse of the SLF4J API. I still argue that the implementation used by the core can be used by plugins and letting arbitrary implementations and arbitrary manipulation of the logging system isn't really that valuable in compared to having a a consistent pattern that's used by so many others. LieGrue, strub - Original Message - From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, November 30, 2012 8:15 PM Subject: Re: [VOTE] Maven 3.1.0 What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 Currently 3.0.4 does not provide either the api or an impl, so I need both as a dependency.., I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log and part of the plugin jar (because it makes most sense to scope it there) What happens when that runs on 3.1.0? Oh and in my custom slf4j impl I actuall knock all the logging levels down by 1, because this tool I am using is too verbose and what it spouts at INFO is really DEBUG... So bypassing my impl would be a bad thing for users On Friday, 30 November 2012, Jason van Zyl wrote: For case 2) I would say only fork if your logging is know to interfere with standard SLF4J practices which I think would be rare. But I'll see how easy it is to implement a flag while I'm looking at this in general. On Nov 30, 2012, at 4:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I tend to agree. There are two use-cases I see that a plugin has for bundling a logging implementation: 1. They are wanting to shunt the logs from the build tool they are invoking on to the user. Typically if they are being good plugins they just take the logging output and shunt it onto org.apache.maven.plugin.Log.info() 2. They are wanting
Re: [VOTE] Maven 3.1.0
On Fri, November 30, 2012 12:33 pm, Mark Struberg wrote: I don't believe it's valid to just let everyone do whatever they want. Well, I think this is the fundamental point we disagree on. Maven is not only a build system but also a container which runs user specific stuff. And a container should try to isolate as much internal details from it's users as he can. So yes, imo we should let everyone do whatever they want! Hm... as far as I am concerned Maven is all about convention over configuration and telling users what is best for them and NOT letting them do whatever they want. Thats what Ant and Gradle are for. By forcing some specific logging mechanism on any users we will heavily restrict plugin programmers. And sometimes even the plugin programmers cannot change anything because the are only 'users' of the library the plugin uses. I have been working on the Android plugin for a long time and I never saw the need to doodle around or worry about logging. I just want Maven to deal with it for me. I personally believe we will introduce quite some backward incompatibility. Yes... maybe, but even if .. that might not be such a bad idea. The more reasons we have to get users to upgrade to latest and greatest versions of Maven the better coverage of it we get and the more relevant feedback to fix things that actually matter. manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Would it be possible to implement something (nasty and rather iki under the covers) along the lines of using say a MavenLoggerFactory.getLogger(Foo.class, ImplementationClass.class, String config). If this variation is used to get a Logger, use ClassWorlds or something to create a new classloader -excluding- the system SLF4J setup, and using the caller is requesting. Is something like that possible at all? Jason van Zyl wrote: I don't believe it's valid to just let everyone do whatever they want. The only problem we've seen thus far is a problem where it's clearly a misuse of the SLF4J API. I still argue that the implementation used by the core can be used by plugins and letting arbitrary implementations and arbitrary manipulation of the logging system isn't really that valuable in compared to having a a consistent pattern that's used by so many others. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Anything is possible but I honestly don't want to do it because I don't really think it's worth it. Just use SLF4J properly, that's your path. I don't think this is really that onerous and deprives developers of their liberty :-) So many systems use SLF4J and I don't think many of them allow magic implementation selection. I don't think we're any different. On Nov 30, 2012, at 1:07 PM, Mark Derricutt m...@talios.com wrote: Would it be possible to implement something (nasty and rather iki under the covers) along the lines of using say a MavenLoggerFactory.getLogger(Foo.class, ImplementationClass.class, String config). If this variation is used to get a Logger, use ClassWorlds or something to create a new classloader -excluding- the system SLF4J setup, and using the caller is requesting. Is something like that possible at all? Jason van Zyl wrote: I don't believe it's valid to just let everyone do whatever they want. The only problem we've seen thus far is a problem where it's clearly a misuse of the SLF4J API. I still argue that the implementation used by the core can be used by plugins and letting arbitrary implementations and arbitrary manipulation of the logging system isn't really that valuable in compared to having a a consistent pattern that's used by so many others. - 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 - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Re: [VOTE] Maven 3.1.0
At the end of the day, either Maven uses a standard logging API inside plugins, or it does not. Using a standard logging API has giant advantages - but it can inconvenience people integrating complex code via plugins. In this thread, there are two approaches to removing that inconvenience: a plugin annotation that changing the logging integration, and use of forking. Both work. I have some sympathy for the view that anything complex enough to care should fork. When people integrate big complex things, it has unpleasant consequences like System.exit() calls. So I'm entirely +1 for the code as it stands, and I see adding an annotation or something to avoid injecting the logging back end as a nice to have. As I wrote before, I'd feel better about the 'stick a fork' in it prescription if we had better reusable forking code. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com wrote: I would go for 2.2. Releasing something and then include it as the default version the same day seems a bit too much for me. I would agree with this. The fact that I was the first one to even notice that 2.3 has issues on the Mac suggests it's not very widely tested. :-( Much like the compiler plugin, I'd let this bake a little more before making it the default. Dan On Thursday, November 29, 2012, Jason van Zyl wrote: I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin 2.4? On Nov 28, 2012, at 12:54 PM, Daniel Kulp dk...@apache.org wrote: On Nov 28, 2012, at 12:33 PM, Jason van Zyl ja...@tesla.io wrote: But what version of the plugin are users going to get? If it's not locked down, they would get 2.3. (maven 3.0.x users get 2.1.3 I think) However, I want to be clear: * The issue ONLY affects Mac users. Other platforms are OK. * The issue only affects users that use the war plugin. * There is an easy workaround of locking down to 2.2 (or to 2.4 once 2.4 is released). * Another work around: adding the -Djava.awt.headless=true flag to the MAVEN_OPTS. * The issue does NOT affect the output of the war plugin. The plugin does exactly what it's supposed to do and produces a proper war. The only problem is the Java Icon that would appear on the Mac Dock for the duration of the build. It doesn't affect the actual build at all. So basically, it affects a relatively small number of maven users, doesn't affect the actual build at all, and has a relatively easy workaround for people that are annoyed by it. Dan On Nov 28, 2012, at 11:54 AM, Daniel Kulp dk...@apache.org wrote: On Nov 28, 2012, at 11:46 AM, Arnaud Héritier aherit...@gmail.com wrote: there is an issue opened about it ? I didn't find it. No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out what was going on. Once we figured it out, he committed a fix before I could even login to JIRA. :-) r1414267 | olamy | 2012-11-27 12:09:54 -0500 (Tue, 27 Nov 2012) | 1 line back tp xstream 1.4.2 to avoid http://jira.codehaus.org/browse/XSTR-709 Dan On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp dk...@apache.org wrote: +1 I've tested this with a few projects and it seems to work. I DON'T like that it updates the war plugin to 2.3 as that version has issues on the Mac related to setting up an awt Toolkit. However, there is a simple workaround of locking the war version down to 2.2 in the project pom (which is something the project in question should have done anyway). Dan On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl ja...@tesla.io wrote: Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-https://repository.apache.org/content/repositories/maven-073/org/apache/maven/apache-maven/3.1.0/the course of true love never did run smooth ... -- Shakespeare -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
