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
Sure, for the specialists these changes offer new opportunities, but
that's a small group.


Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl <jason@tesla.io>:

On Dec 7, 2012, at 12:15 PM, Robert Scholte 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


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.)


Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies <

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 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

Are there other proposals which might help increasing backward

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)


----- Original Message -----

From: Benson Margulies <bimargulies@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
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 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>


Daniel, please think through these old project scenarios. Those old
projects did ship their own slf4j impl + config and parsed their own


and extracted information. They will now just fall on their knees


the logs are no longer available for them. Instead they will be


in the maven logs which could be anywhere from a plugin point of view.

This is not fixed, this is broken imo.


----- Original Message -----
From: Daniel Kulp <dkulp@apache.org>
To: Maven Developers List <dev@maven.apache.org>
Sent: Friday, December 7, 2012 1:49 PM
Subject: Re: [VOTE] Maven

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase