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 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 >>>>>> <useSlf4j>true</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 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 y >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Daniel Kulp >>>>>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>>>>> Talend Community Coder - http://coders.talend.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>>>>>> Spring Batch in Action: <http://s.apache.org/HOq> >> http://bit.ly/bqpbCK >>>>>>> Blog: http://garygregory.wordpress.com >>>>>>> Home: http://garygregory.com/ >>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> >> >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
