how much memory will be freed by the soft reference? if it's not a big
chunk, most likely not worth it, soft references are released only
when your VM is really, really in trouble. by the time it gets
released, you've been slowed down by repeatedly hitting the ceiling of
your memory and CGed freque
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
log4j2 at least from the feature branch works too. There was no significant
a difference in build time between 3.0.4 the log4j2 and the logback
versions, though I am not clear as to whether the log4j2 branch has been
updated with the latest fixes from the last round of 3.1.0 RCs.
It would be good
FUD FUD FUD
$ git clone git://github.com/qos-ch/slf4j.git
$ cd slf4j/
$ git checkout v1.5.11
$ mvn -version
Apache Maven (Logback) 3.1-SNAPSHOT
(7f9e280522379fc0f3ac09f4d81e8188cdb54192; 2012-12-11 22:54:30+)
Maven home: /Users/stephenc/apache/mvn-logback
Java version: 1.6.0_37, vendor: Apple
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
Oh dear me Mark. Please for the love of everything Maven please reconsider
what you just posted.
Are you really sure that one cannot build slf4j-1.5 with the proposed 3.1.0
versions?
Please try it and if you have found an issue post the results for all to
see.
I personally would be "shocked and
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
You have to distinguish between plugin dependencies and project 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 version of slf4j-1.5
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
btw, jason mentioned that lots of apache frameworks already use SLF4J. And he
prominently mentioned CXF.
Now here comes the bitter truth: THEY DROPPED IT AGAIN!
They now use a java.util.logging.Logger facade to redirect to log4j, slf4j or
whatever
http://svn.apache.org/repos/asf/cxf/trunk/api/s
+1 for logback
On Tue, Dec 11, 2012 at 9:28 PM, 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
> explai
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!
So -1 on logback
LieGrue,
strub
- Original Message -
> Fro
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
Thanks for report.
Just fixed.
Those files was never added in any path of our scm. (So can happen for
some others files never added, I have restored /images too).
Note: there is backup of our site in /www/maven-old.apache.org on people.a.o
I can try to explain how that works (or at least what I h
sure I will.
2012/12/11 Kristian Rosenvold :
> If you could help me with surefire this week I would be /really/ happy
> and promise to study your changes so I can do it for other projects
> later ;)
>
> Kristian
>
> Den 11. des. 2012 kl. 00:23 skrev Olivier Lamy :
>
>> I have updated documentation
99,9% sure it was with others xsds like assembly & co
On Tue, Dec 11, 2012 at 9:41 AM, Tamás Cservenák wrote:
> Unsure was POM XSD "officially" available or not from URL (as documented
> for example here http://maven.apache.org/pom.html#Quick_Overview):
> http://maven.apache.org/xsd/maven-4.
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
Unsure was POM XSD "officially" available or not from URL (as documented
for example here http://maven.apache.org/pom.html#Quick_Overview):
http://maven.apache.org/xsd/maven-4.0.0.xsd
but it's gone too
Thanks,
~t~
On Mon, Dec 10, 2012 at 3:51 PM, Olivier Lamy wrote:
> Hi,
> It's now live.
>
36 matches
Mail list logo
