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

Reply via email to