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: Site staging strategy
It appears that the attachments got snipped somewhere, so making the images available via normal browsing: *Problem:* I essentially want to know how to inject a site stage structure parser in doxia for use with maven-site-plugin, since the maven-site-plugin's usage of Doxia for running site:stage seems to assume that there is a 1:1 relation between pom parents and modules. I struggle to find a simple way to instruct the maven-site-plugin how to structure its stage site when a project has defined another parent pom than the project which included it in the build reactor. In the images below, this is the case for X-Y-api and the other projects dyed slightly yellow. *Image legend*: In the images below, solid lines indicate the reactor/module dependencies, and dotted line arrows indicate parent relations between poms. Reactor structure, and parent inheritance: http://www.jguru.se/apache/maven/site/reactor_and_inheritance.png Desired site structure: http://www.jguru.se/apache/maven/site/desired_stage_site.png 2012/12/7 Anders Hammar and...@hammar.net Lennart, Your attachments are missing. /Anders On Thu, Dec 6, 2012 at 11:49 PM, Lennart Jörelid lennart.jore...@gmail.comwrote: Hello all, I have a few reactors where two separate parent poms exist; one parent is used exclusively for reactor projects [with packagingpom/packaging] and the other parent is exclusively used for all other projects [with packaging... something not pom .../packaging]. The build itself works as expected - but the *mvn site:stage* builds a structure connecting only the irrelevant parts (i.e. the reactor poms having module definitions); the relevant projects (i.e the non-reactor projects) are left out of the staged site, and site navigation does not work in the staged site. After a tad of looking around in Doxia, I am not quite certain what should be customized to handle the difference in preferred site stage structure. There is likely a simple solution for how to retieve a staged site with desired/relevant content, but I have not found it. Could you direct me here? An example reactor structure is illustrated/attached in the image reactor_and_inheritance.png, where solid lines indicate the reactor/module dependencies, and dotted line arrows indicate parent relations between poms. Also attaching the desired site stage structure. -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid +==+ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==+
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 on
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 to
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... At
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 to*. At
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I mentioned to Kristian that it wouldn't be hard to fix and that I would fix it before we released. Just been traveling this week. I'll fix it this weekend when I get home. On Dec 7, 2012, at 6:04 AM, Benson Margulies bimargul...@gmail.com wrote: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Sent: Friday, December 7, 2012 12:48 PM Subject: Re: [VOTE] Maven 3.1.0 But not all of those *need to*. At least until now they have needed to, but going forward they may not need to if we are giving them an slf4j impl to hang their hat off. There will always be some special case plugins that have a legitimate need to do funky logging stuff. We need a strategy for those plugins. Jason's proposal for those cases was that they should fork a JVM. That works if you don't need to channel objects back and forth.
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Kristian, I'm going to look at problem with the logging while embedding and Hervé wants to look at the SLF4J isolation. From what I understand in talking to Ceki, for each classloader SLF4J can be initialized so it appears theoretically possible to block the all SLF4J from reaching a plugin and it will still be able to initialized its own SLF4J system though it will not be connected to the core's. So then it's a matter of deciding on sensible defaults and I agree with Anders here in that the default should be to pass on the core's SLF4J implementation. I think exceptional cases should use a flag for exceptional cases. This still will not help Sonar today but we can also add some heuristics to help plugins like the Sonar plugin. If we inspect the dependencies and see SLF4J is there we can block SLF4J from the plugin's classloader. I'm not sure yet how this will work for Mojo.log() or injected loggers but that might not matter for plugins that get no SLF4J system from the core because its doing it's own thing. Hervé I will assume you're looking at this. Let me know if you need any help. I don't plan on introducing a logging framework in this version. That's a subsequent discussion. On Dec 7, 2012, at 7:39 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: The version that is currently staged (code name alpha-5 in my book) has an unsolved problem with the logging and verifier. I assume we'll stage a new version (code name beta-1) when that's done, at which point I'm more than ready to ship. I'm not fixing any more stuff on core now, and I'm half-assuming jason will fix the logging. Jason, do ping me on irc if you need a second set of eyes on solving the problem, even though I'm incompetent with logging ;) Kristian 2012/12/7 Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristiathe loggingn found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly
Re: [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
custom lifecycle without inheritance
Hello, I am trying to invoke a single goal before another (ant-based) Mojo executes. Due to http://jira.codehaus.org/browse/MNG-5405 I cannot just do exeecutiongoalfoo:bar/goal/execution in the mojo.xml for the plugin. So instead, I've defined a lifecycle.xml, with only one goal in it. This works fine as a workaround for now, except that the forked lifecycle inherits the goals from the lifecycle of the project that is running the mojo in the first place. In some of our projects, we have a lot of custom mojos running, even in the initialize phase. So...is there a way to: a) define a new phase name (I don't think so) or b) make it so that the lifecycle.xml only runs what is defined there and does not inherit the project's lifecycle? -- Ben Tatham Software Developer Nanometrics Inc. +1 613-592-6776 x254 http://www.nanometrics.ca
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io: On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a useSlf4jtrue/useSlf4j inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io: On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
From this user's POV, I want colors out of the box, just like you get colors out of the box with the git CLI. You do not have to turn on anything, it just works. Gary On Fri, Dec 7, 2012 at 4:03 PM, Robert Scholte rfscho...@apache.org wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io: On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven 3.1.0 Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. I don't consider them broken. I consider them fixed.Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg strub...@yahoo.de wrote: The final proposal that I see is where we give a metadata flag (defaults to false) which if true sets up an isolated classloader for the plugin allowing the plugin to use its own slf4j Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Do you still watch TV in black and white? ;) On Fri, Dec 7, 2012 at 4:28 PM, Jesse McConnell jesse.mcconn...@gmail.comwrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
+1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Well, then at least a property to be set in ~/.m2/settings.xml to switch colors on would be nice :-). I for one would be much more interested in introducing a switch which allows to suppress INFO but not WARN :-). Regards Mirko On Fri, Dec 7, 2012 at 10:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Even if I like the colorized console and couldn't leave without it now I would probably vote in favor to have it off by default because : * It is difficult to define the default font color that won't be unreadable on the user console (white on white, ) * Like always, windows sucks and I didn't succeeded to have it working with Jansi on a Windows XP 64b and saw a bug reported on Windows 7 64b. If this is off by default, I would like to be able to activate it by a little config change in the distro or better with a system property or a setting entry to not have to update the config each time I upgrade ( or rebuild ) Maven Arnaud On Fri, Dec 7, 2012 at 10:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 from me On Friday, 7 December 2012, Jesse McConnell wrote: I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com javascript:; On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: Wrong checksums for org/apache/maven/its/maven-core-it-support/1.0 in Maven-Central
It's been fixed. See ticket. /Anders (mobile) Den 7 dec 2012 22:46 skrev Mirko Friedenhagen mfriedenha...@gmail.com: Hello, artifactory choked on https://issues.sonatype.org/browse/MVNCENTRAL-271, probably central wants maven to fix this and sync again. However there is not issue tracker given in http://repo1.maven.org/maven2/org/apache/maven/its/maven-core-it-support/1.0/maven-core-it-support-1.0.pom , so where to report this :-)? Regards Mirko - 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
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: Wrong checksums for org/apache/maven/its/maven-core-it-support/1.0 in Maven-Central
Sorry for the noise, last time I reported something coming from apache.org, Central sent me back to Apache :-). Regards Mirko On Fri, Dec 7, 2012 at 11:15 PM, Anders Hammar and...@hammar.net wrote: It's been fixed. See ticket. /Anders (mobile) Den 7 dec 2012 22:46 skrev Mirko Friedenhagen mfriedenha...@gmail.com: Hello, artifactory choked on https://issues.sonatype.org/browse/MVNCENTRAL-271, probably central wants maven to fix this and sync again. However there is not issue tracker given in http://repo1.maven.org/maven2/org/apache/maven/its/maven-core-it-support/1.0/maven-core-it-support-1.0.pom , so where to report this :-)? Regards Mirko - 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:
