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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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,
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
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
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
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
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
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
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
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.)
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
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
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
41 matches
Mail list logo
