I'll let folks focus on their evaluations and I'll work on the sample plugins
and classloader isolation.
On Dec 12, 2012, at 9:23 AM, Stephen Connolly
wrote:
> On Wednesday, 12 December 2012, Daniel Kulp wrote:
>
>>
>> On Dec 12, 2012, at 8:45 AM, Stephen Connolly <
>> stephen.alan.conno...@
On Wednesday, 12 December 2012, Daniel Kulp wrote:
>
> On Dec 12, 2012, at 8:45 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > Another criteria that people should pay attention to is whether the
> > implementation supports Mapped Diagnostic Contexts
> > http://logback.qos.
On Wed, Dec 12, 2012 at 8:38 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Another criteria that people should pay attention to is whether the
> implementation supports Mapped Diagnostic Contexts
> http://logback.qos.ch/manual/mdc.html
>
> AFAIU this may rule out JUL as a seriou
On Dec 12, 2012, at 8:45 AM, Stephen Connolly
wrote:
> Another criteria that people should pay attention to is whether the
> implementation supports Mapped Diagnostic Contexts
> http://logback.qos.ch/manual/mdc.html
>
> AFAIU this may rule out JUL as a serious implementation... In other words
Another criteria that people should pay attention to is whether the
implementation supports Mapped Diagnostic Contexts
http://logback.qos.ch/manual/mdc.html
AFAIU this may rule out JUL as a serious implementation... In other words
when we want to start using MDCs to make it easier to navigate the
Another criteria that people should pay attention to is whether the
implementation supports Mapped Diagnostic Contexts
http://logback.qos.ch/manual/mdc.html
AFAIU this may rule out JUL as a serious implementation... In other words
when we want to start using MDCs to make it easier to navigate the
I ran the CXF build like:
mvn -Pfastinstall -T8 -o
using the latest on the two branches as of 11pm last night:
3.0.4: 1:16
log4j2: 1:12
logback: 1:19
Ran each 3 times and results were fairly consistent.Thus, for me using
parallel builds, log4j2 is the fastest, but the difference is alm
The idea behind these binaries is to give everyone the opportunity to make
decisions with regards to the technical gates:
1. Does it pass the integration tests
2. Is it roughly equivalent in terms of performance to 3.0.4 (can be better
or up to say 5% worse)
There are additional criteria people c
I have built some binaries for people to play with:
http://people.apache.org/~stephenc/
MD5 (apache-maven-3.1.0-pre-jul.tar.gz) = dd40afbfa64ab53f614ede19385e4a48
MD5 (apache-maven-3.1.0-pre-jul.zip) = 731fe7136e96e2027d145d993d917f20
MD5 (apache-maven-3.1.0-pre-log4j.tar.gz) = 63fead6accb60ca52c
I am working on getting some branches for different options.
I think I have the logging/slf4j-jul branch done...
I think my logging/slf4j-log4j2 branch is correct
I am fairly certain my logging/slf4j-logback branch is correct
My logging/slf4j-log4j (i.e. 1.2) branch needs some tweaks
If somebo
turbo when he is
really hot after benchmarks (even singlethreaded).
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List
> Cc:
> Sent: Wednesday, December 12, 2012 9:35 AM
> Subject: Re: Logback in Maven Core
>
> Yeah,
Can we get a set of baseline git hashes for any versions of maven that we
are comparing. I might see if I can pull logback out of the latest RC and
put log4j2 and some other impls in its place so we can get some real apples
for apples comparisons going
On 12 December 2012 08:35, Kristian Rosenvol
Yeah, measuring performance on modern cpu's is totally borked. To get
any real measurements one probably needs to to average of 100 non-stop
builds or similar, to counter for all the dark magics intel do with
temperature-based overclocking.
I think I've seen somewhere that it's possible to disable
Oh - FWIW I'm running on OSX 10.7.5 with a 2.5 GHz Intel Core i7 with 16GB of
memory.
Ralph
On Dec 12, 2012, at 12:27 AM, Ralph Goers wrote:
> I checked out Maven and used its build as a comparison. First, I ran the
> log4j 2 build and it was taking around 59 seconds. I then changed the
>
I checked out Maven and used its build as a comparison. First, I ran the log4j
2 build and it was taking around 59 seconds. I then changed the log4j2.xml to
remove the colors. I then got an average time for Log4j 2 of 54.76s and for
Logback I get an average of 55.225s. I consider these diff
Well I am not going to tar and feather log4j2 based on one set of runs on
my machine. I would like somebody else to repeat and confirm first as there
could have been some background OS update or other process stealing CPU
while doing the 3 log4j2 runs.
Also I do not know if I am comparing the same
Finally some interesting numbers, and if (heaven forbid) this decision
should be based on
technical grounds, this is one of the first significant pieces to come
up in this discussion.
Since I am quite unfamiliar with logging (I use loose coupling and
tests instead ;), I took the opportunity to rea
Le mardi 11 décembre 2012 20:27:15 Jason van Zyl a écrit :
> Would be easy enough to create a template method in MavenCli which in which
> subclasses can override to do any setup of the underlying logging system.
> Much like the createModelProcessor() method in the MavenCli currently.
yes
IMHO, thi
Would be easy enough to create a template method in MavenCli which in which
subclasses can override to do any setup of the underlying logging system. Much
like the createModelProcessor() method in the MavenCli currently.
On Dec 11, 2012, at 7:39 PM, Hervé BOUTEMY wrote:
> same for me
>
> with
same for me
with one precision: IMHO, the few places where we'll have to write
implementation-specific code need to be placed in a separate class to ease
changing implementation
Regards,
Hervé
Le mardi 11 décembre 2012 16:19:12 Daniel Kulp a écrit :
> My thoughts:
> 99.5% (or more) of the mav
OK. In the absence of anyone else giving some numbers I have been running
some tests.
I have been comparing 3.0.4 with logback (using git hash
7f9e280522379fc0f3ac09f4d81e8188cdb54192) and log4j (using git hash
0f71ae559e19aa3eb5e4f5c981d9e20e63cc2e3e)
The first test was building GIT hash of
e20a
gt;> dependencies.
>>>
>>> For plugin dependencies this can get solved with a new switch in the
>>> maven-plugin-plugin.
>>> But for user projects this is more complicated. E.g you yourself would
>>> not even be able to compile a bugfix vers
ven!
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> - Original Message -
>> > From: ceki
>> > To: Maven Developers List
>> > Cc:
>> > Sent: Tuesday, December 11, 2012 10:13 PM
>> > Subject: Re: L
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies wrote:
> I want to gently argue with a part of Dan Kulp's position. The PMC
> established the class B dependency rule in response to a particular
> conflict within this community. From my point of view, whether or not
> that conflict is entirely in
en Developers List
> > Cc:
> > Sent: Tuesday, December 11, 2012 10:13 PM
> > Subject: Re: Logback in Maven Core
> >
> > On 11.12.2012 21:28, Mark Struberg wrote:
> >
> >> Folks, don't you see it? we cannot use logback as this is a
> >> Lo
On Tue, Dec 11, 2012 at 5:32 PM, Daniel Kulp wrote:
>
> On Dec 11, 2012, at 5:07 PM, Benson Margulies wrote:
>
>> I want to gently argue with a part of Dan Kulp's position. The PMC
>> established the class B dependency rule in response to a particular
>> conflict within this community. From my po
On Dec 11, 2012, at 5:07 PM, Benson Margulies wrote:
> I want to gently argue with a part of Dan Kulp's position. The PMC
> established the class B dependency rule in response to a particular
> conflict within this community. From my point of view, whether or not
> that conflict is entirely in o
On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies wrote:
>
> If we ever got that far, I would argue pretty strenuously against a
> PMC-level rejection of something just based on being EPL. A class-B
> license is a perfectly legitimate dependency.
As would I. If we were talking about binding our
-1.5 anymore with this new version
of maven!
LieGrue,
strub
- Original Message -
> From: ceki
> To: Maven Developers List
> Cc:
> Sent: Tuesday, December 11, 2012 10:13 PM
> Subject: Re: Logback in Maven Core
>
> On 11.12.2012 21:28, Mark Struberg wrote:
>
>
I want to gently argue with a part of Dan Kulp's position. The PMC
established the class B dependency rule in response to a particular
conflict within this community. From my point of view, whether or not
that conflict is entirely in our past, logback is not an example of
the problem that the rule
On 11 December 2012 21:49, Olivier Lamy wrote:
> 2012/12/11 Stephen Connolly :
> > On Tuesday, 11 December 2012, Daniel Kulp wrote:
> >
> >>
> >>
> >> My thoughts:
> >> 99.5% (or more) of the maven users will not care one way or another what
> >> logging impl we use. They won't configure anythin
On 11 December 2012 21:39, Stephen Connolly wrote:
>
>
> On Tuesday, 11 December 2012, Daniel Kulp wrote:
>
>>
>>
>> My thoughts:
>> 99.5% (or more) of the maven users will not care one way or another what
>> logging impl we use. They won't configure anything beyond -X. They won't
>> try chang
2012/12/11 Stephen Connolly :
> On Tuesday, 11 December 2012, Daniel Kulp wrote:
>
>>
>>
>> My thoughts:
>> 99.5% (or more) of the maven users will not care one way or another what
>> logging impl we use. They won't configure anything beyond -X. They won't
>> try changing loggers. They won't m
On Tuesday, 11 December 2012, Daniel Kulp wrote:
>
>
> My thoughts:
> 99.5% (or more) of the maven users will not care one way or another what
> logging impl we use. They won't configure anything beyond -X. They won't
> try changing loggers. They won't muck with the configs. Etc.. They
> j
My thoughts:
99.5% (or more) of the maven users will not care one way or another what
logging impl we use. They won't configure anything beyond -X. They won't try
changing loggers. They won't muck with the configs. Etc.. They just run
"mvn" and expect it to work.
For the remaining
On 11.12.2012 21:28, Mark Struberg wrote:
> Folks, don't you see it? we cannot use logback as this is a
> LocationAwareLogger and would break all projects which use slf4j < 1.6
> and older. Please go back to the original mail from 4 month where
> Ceki himself explained it!
Hi Mark,
You are ass
5 PM
> Subject: Re: Logback in Maven Core
>
> +1 on for logback.
>
> However, is it possible to switch to Log4j2 by manually repackage
> maven distribution?
>
> Thanks
>
> -D
>
> On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar wrote:
>> I'm +1
h where Ceki himself
> explained it!
>
> So -1 on logback
>
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: Anders Hammar
> > To: Maven Developers List
> > Cc:
> > Sent: Tuesday, December 11, 2012 7:57 PM
> > Subject: Re:
Message -
> From: Anders Hammar
> To: Maven Developers List
> Cc:
> Sent: Tuesday, December 11, 2012 7:57 PM
> Subject: Re: Logback in Maven Core
>
> I'm +1 for logback as the slf4j impl.
>
> /Anders
>
>
> On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl wro
My understanding is that whichever choice is made, there will need to be
some support code in CLI to allow for CLI options for tweaking the logging
level (i.e. -X to turn on DEBUG). As I do not yet know what that code will
look like I cannot say if a straight remove selected impl and drop in
altern
+1 on for logback.
However, is it possible to switch to Log4j2 by manually repackage
maven distribution?
Thanks
-D
On Tue, Dec 11, 2012 at 10:57 AM, Anders Hammar wrote:
> I'm +1 for logback as the slf4j impl.
>
> /Anders
>
>
> On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl wrote:
>
>> Hi,
>>
I'm +1 for logback as the slf4j impl.
/Anders
On Tue, Dec 11, 2012 at 3:32 AM, Jason van Zyl wrote:
> Hi,
>
> I looked around a bit more today and I don't think SLF4J Simple is viable
> long term, I don't want to patch it anymore as I would have to do a day's
> work to make changes that keep t
Stephen,
Thanks for the complete explanation, I'm a little logging beleaguered :-)
On Dec 11, 2012, at 4:18 AM, Stephen Connolly wrote:
> Given that some people are already confused as to what the exact question
> is
> I think we should clarify exactly what is the decision that is being asked.
+1 for logback
--
Regards,
Igor
On 2012-12-10 9:32 PM, Jason van Zyl wrote:
Hi,
I looked around a bit more today and I don't think SLF4J Simple is viable long
term, I don't want to patch it anymore as I would have to do a day's work to
make changes that keep the performance levels up, get it
+1 for logback!
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Tue, Dec 11, 2012 at 3:18 AM, Stephen Connolly wrote:
> Given that some people are already confused as to what the exact question
> is
> I think we should clarify exactly what is the decision that is being asked.
>
> There has alr
Given that some people are already confused as to what the exact question
is
I think we should clarify exactly what is the decision that is being asked.
There has already been a decision to use the slf4j API for logging within
core.
* The vast majority of plugins will still use the Maven Log int
Hi,
Think for everyday users (i'm part of them) it doesnt make so much
difference so since the logs are the same and the impl is easier logback
sounds good.
Le 11 déc. 2012 08:14, "Ansgar Konermann"
a écrit :
> Hi,
>
> please go for logback. I really wondered why slf4j was initially chosen at
>
Hi,
please go for logback. I really wondered why slf4j was initially chosen at
all, given logback is available and mature. We've been using logback at
work in production for quite some time now and are very pleased. So yes,
using logback in Maven is fine.
Regards
Ansgar
Am 11.12.2012 03:33 schri
Hi,
I looked around a bit more today and I don't think SLF4J Simple is viable long
term, I don't want to patch it anymore as I would have to do a day's work to
make changes that keep the performance levels up, get it reviewed and released,
and I honestly don't think it's worth it anymore. I wou
49 matches
Mail list logo
