maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
Date Fri, 07 Dec 2012 20:18:43 GMT
On Fri, Dec 7, 2012 at 3:15 PM, Robert Scholte <rfscholte@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
> <bimargulies@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 <struberg@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 <bimargulies@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 <garydgregory@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 <struberg@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 <dkulp@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
>>>>
>>>> <struberg@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.connolly@gmail.com>
>>>>>>
>>>>>>  >>>  To: Maven Developers List <dev@maven.apache.org>;
>>>>
>>>> Mark Struberg
>>>>>>
>>>>>>  > <struberg@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 <anders@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
>>>>>>
>>>>>>  >>>>>  <bimargulies@gmail.com>
>>>>>>  >>>>>>   wrote:
>>>>>>  >>>>>>   > > On Thu, Nov 29, 2012 at 11:05
PM,
>>>>
>>>> Jason van Zyl
>>>>>>
>>>>>>  >>>>>  <jason@tesla.io>
>>>>>>  >>>>>>   wrote:
>>>>>>  >>>>>>   > > > On Nov 29, 2012, at 5:56
PM,
>>>>
>>>> Benson
>>>>>>
>>>>>>  > Margulies
>>>>>>  >>>>>  <bimargulies@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-unsubscribe@maven.apache.org
>>>>>>  >>  For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>  >>
>>>>>>  >
>>>>>>  > --
>>>>>>  > Daniel Kulp
>>>>>>  > dkulp@apache.org - http://dankulp.com/blog
>>>>>>  > Talend Community Coder - http://coders.talend.com
>>>>>>  >
>>>>>>  >
>>>>>>  >
>>>>
>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>  > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>  > For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>  >
>>>>>>
>>>>>>  ---------------------------------------------------------------------
>>>>>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>  For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>  E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message