I'm doing more comparison for myself, that can be useful for others
for the config format:
http://logback.qos.ch/manual/configuration.html
vs
http://logging.apache.org/log4j/2.x/manual/configuration.html
I don't see much difference
Notice there is no dtd nor schema for both
I like having some he
Le samedi 1 décembre 2012 12:10:43 Stuart McCulloch a écrit :
> You might want to take a look at
> http://logback.qos.ch/manual/layouts.html#coloring for additional
> background
thank you Stuart, really useful
I made the same research for log4j2, to continue my personal comparison and
found "hig
I'm going to hack on the Aether branch for the rest of the day, I'll check in
tomorrow morning to see what others think about the release.
Thanks,
Jason
--
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jva
On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY wrote:
> Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
>> [1]:
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
>
>
> just for side-by-side comparison:
> https://github.com/qos-ch/logback/graphs/contributo
Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
> [1]:
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
just for side-by-side comparison:
https://github.com/qos-ch/logback/graphs/contributors
-
Olivier can clarify but appears to me to ship all implementations with
configurations to let the user flip.
I don't think anyone can honestly justify shipping Log4J2 by default, I think
Logback is appropriate so he's trying to accommodate everyone's PoV. But I
still think we have to pick an imp
On Dec 1, 2012, at 2:24 PM, Mark Struberg wrote:
>
>> How many times does someone really need a different implementation?
>
> Sorry Jason, thats bollocks and you know it.
>
You looked at the the question and presumed an answer. You're assuming my is
never. The answer is not very often, whi
On Sat, Dec 1, 2012 at 5:32 PM, Jason van Zyl wrote:
>
> On Dec 1, 2012, at 2:27 PM, Olivier Lamy wrote:
>
>>
>> I just try to make more than one happy so what is your reason ?
>>
>
> That shipping multiple implementations means we have to support them for no
> particular reason. I think that se
On Dec 1, 2012, at 2:27 PM, Olivier Lamy wrote:
>
> I just try to make more than one happy so what is your reason ?
>
That shipping multiple implementations means we have to support them for no
particular reason. I think that setup is fairly convoluted for users, and still
we have really de
If a script or plugin was provided to make changing the implementation easy I
think that would be better. That can be made as simple. I think shipping
optional components is generally a bad practice. It would be like shipping all
the wagon/aether implementations to let people pick. Not really sc
2012/12/1 Jason van Zyl :
>
> On Dec 1, 2012, at 2:17 PM, Olivier Lamy wrote:
>
>> 2012/12/1 Jason van Zyl :
>>> On Dec 1, 2012, at 1:44 PM, Olivier Lamy wrote:
>>>
>
> I don't think that's particularly easy and additionally opens us up to
> having to specifically support any SLF4J i
On Sat, Dec 1, 2012 at 2:39 PM, Olivier Lamy wrote:
> Hi,
>
> Why do we have to force our users to a specific logging implementation
> than we choose ?
>
Doesn't the product have to establish a default? Isn't that the one
"forced" on the users?
Substitution of the default for alternate impleme
> How many times does someone really need a different implementation?
Sorry Jason, thats bollocks and you know it.
> That is the pattern of most forms of
> integration because trying to account for many implementations interacting
> together have unknown side affects.
You are wrong and ri
On Dec 1, 2012, at 2:17 PM, Olivier Lamy wrote:
> 2012/12/1 Jason van Zyl :
>> On Dec 1, 2012, at 1:44 PM, Olivier Lamy wrote:
>>
I don't think that's particularly easy and additionally opens us up to
having to specifically support any SLF4J implementation which I don't
2012/12/1 Jason van Zyl :
> On Dec 1, 2012, at 1:44 PM, Olivier Lamy wrote:
>
>>>
>>> I don't think that's particularly easy and additionally opens us up to
>>> having to specifically support any SLF4J implementation which I don't think
>>> is wise.
>>>
>> if documented that's not really complic
Milestones are great idea, and there has already been a few (just named the
same! :-).
+1 for 3.1.0
Nice infra improvements including SLF4J. Appreciating you patiently RM'ing
this Jason...
(and +1 for Logback; haven't used Log4j in 4 years).
On Sat, Dec 1, 2012 at 2:29 PM, Jason van Zyl wrote
On Dec 1, 2012, at 1:44 PM, Olivier Lamy wrote:
>>
>> I don't think that's particularly easy and additionally opens us up to
>> having to specifically support any SLF4J implementation which I don't think
>> is wise.
>>
> if documented that's not really complicated.
>
So the process would be
On Sat, Dec 1, 2012 at 4:44 PM, Olivier Lamy wrote:
> 2012/12/1 Jason van Zyl :
>>
>> On Dec 1, 2012, at 12:39 PM, Olivier Lamy wrote:
>>
>>> Hi,
>>>
>>> Why do we have to force our users to a specific logging implementation
>>> than we choose ?
>>
>> My counter argument is why don't we? That is
+1 (non-binding), tested with two projects.
Regards Mirko
On Sat, Dec 1, 2012 at 11:37 AM, Robert Scholte wrote:
> +1
>
> Op Thu, 29 Nov 2012 22:18:35 +0100 schreef Tony Chemit
> :
>
>
>> On Wed, 28 Nov 2012 18:26:13 -0600
>> Paul Gier wrote:
>>
>> +1 (nb)
>>
>> works fine to me
>>
>> thanks,
>
2012/12/1 Jason van Zyl :
>
> On Dec 1, 2012, at 12:39 PM, Olivier Lamy wrote:
>
>> Hi,
>>
>> Why do we have to force our users to a specific logging implementation
>> than we choose ?
>
> My counter argument is why don't we? That is the pattern of most forms of
> integration because trying to ac
On Dec 1, 2012, at 12:39 PM, Olivier Lamy wrote:
> Hi,
>
> Why do we have to force our users to a specific logging implementation
> than we choose ?
My counter argument is why don't we? That is the pattern of most forms of
integration because trying to account for many implementations interac
Hi,
The votes has passed with the following result.
+1 (binding): Robert, Hervé, Olivier
+1 (non binding): Anders
I will continue the release process.
Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
On Dec 1, 2012, at 15:23, Stephen Connolly
wrote:
> -1 for 3.1.0-m1
>
> +1 for 3.1.0
>
> Let's just stop faffing about and get cutting releases already
+1, if it is stable, release it. Backward compatibility must be doc'd.
Gary
>
> -Stephen
>
>
> On 1 December 2012 20:17, Robert Scholte wrote
Great emails here. My mention of log4j2 is to get a hard core customer
- maven - in order to make log4j2 better. Whether that is in the best
interest of Maven users and developers is a different question which
you guys know best. I'm fine with Maven jumping on the logback
bandwagon. If there are te
Hi,
Why do we have to force our users to a specific logging implementation
than we choose ?
We can propose variants and at least one as a workaround to maybe fix
sonar issue.
So what I do in the branch called dynamic-logging-impl is a "dynamic"
way of loading the implementation users prefers (def
I will cut the release :-)
But I don't think the milestones are a bad idea. It's a clear indicator of what
it is and we have already seen one case where something is not going to work.
Maybe during the milestones we can figure out how not to break Sonar which
would be nice. It might give us a c
> In any case doing a choice nowadays for 3.1.0 won't prevent us to change it
> in the future. I really hope that the ability to switch from a logger
> implementation to another won't require several days of developments or I
> really missed something about it.
>
Well, very likely it would affect
Am 12/01/12 19:03, schrieb Hervé BOUTEMY:
> Le samedi 1 décembre 2012 18:52:51 Dennis Lundberg a écrit :
>> I would -1 any suggestion to start using the "beta" moniker again, at
>> least for the changes made this far.
> I completely agree
> would it be more a milestone, to show the "stable but work
-1 for 3.1.0-m1
+1 for 3.1.0
Let's just stop faffing about and get cutting releases already
-Stephen
On 1 December 2012 20:17, Robert Scholte wrote:
> +1 for 3.1.0-m1
>
> Robert
>
> Op Sat, 01 Dec 2012 19:32:35 +0100 schreef Benson Margulies <
> bimargul...@gmail.com>:
>
>
> And +1 to Mark
Makes sense, that is the process at Eclipse and works well. Clear indication
that it's something new to play with but might not want to rely on it in
production quite yet.
On Dec 1, 2012, at 12:17 PM, Robert Scholte wrote:
> +1 for 3.1.0-m1
>
> Robert
>
> Op Sat, 01 Dec 2012 19:32:35 +0100 s
+1 for 3.1.0-m1
Robert
Op Sat, 01 Dec 2012 19:32:35 +0100 schreef Benson Margulies
:
And +1 to Mark for noting that we don't veto releases, which is
something I'd meant to add in as a reminder.
On Sat, Dec 1, 2012 at 1:08 PM, Mark Struberg wrote:
+1 for 3.1.0-m1
LieGrue,
strub
---
On Dec 1, 2012, at 10:23 AM, Benson Margulies wrote:
> On Sat, Dec 1, 2012 at 1:08 PM, Jason van Zyl wrote:
>>
>> On Dec 1, 2012, at 1:42 AM, Arnaud Héritier wrote:
>>
>>> Ok. Yes that's sure it has to be discussed. That's why I reopened the
>>> subject.
>>> About the implementation :
>>> *
Hi,
Yes of you have some time free, I'll be happy if you can do it. I
saw it just before leaving home this evening. I won't be able to fix
before (at least tomorrow).
Sorry for this. I didn't think of this side effect and forgot to
check the branch before to push it
Cheers.
-
Arnau
OK, 3.1.1 or 3.1-m2 or whatever before Christmas. Let's get this fish
out of the store and move on to the next one.
On Sat, Dec 1, 2012 at 1:31 PM, Gary Gregory wrote:
> Oh do please give us a color console for Christmas :)
>
> Gary
>
> On Dec 1, 2012, at 12:47, Jason van Zyl wrote:
>
>> I alrea
And +1 to Mark for noting that we don't veto releases, which is
something I'd meant to add in as a reminder.
On Sat, Dec 1, 2012 at 1:08 PM, Mark Struberg wrote:
> +1 for 3.1.0-m1
>
>
> LieGrue,
> strub
>
>
>
> - Original Message -
>> From: Hervé BOUTEMY
>> To: Maven Developers List
>
Oh do please give us a color console for Christmas :)
Gary
On Dec 1, 2012, at 12:47, Jason van Zyl wrote:
> I already have started a logback version, but I don't think this should
> affect rolling the 3.1.0.
>
> On Dec 1, 2012, at 6:57 AM, Arnaud Héritier wrote:
>
>> I pushed the prototype de
On Sat, Dec 1, 2012 at 1:08 PM, Jason van Zyl wrote:
>
> On Dec 1, 2012, at 1:42 AM, Arnaud Héritier wrote:
>
>> Ok. Yes that's sure it has to be discussed. That's why I reopened the
>> subject.
>> About the implementation :
>> * as a user I have really no preference, I just want the feature
>>
+1 for 3.1.0-m1
LieGrue,
strub
- Original Message -
> From: Hervé BOUTEMY
> To: Maven Developers List
> Cc:
> Sent: Saturday, December 1, 2012 7:03 PM
> Subject: Re: 3.1.0 decision making
>
> Le samedi 1 décembre 2012 18:52:51 Dennis Lundberg a écrit :
>> I would -1 any suggestion
On Dec 1, 2012, at 1:42 AM, Arnaud Héritier wrote:
> Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
> About the implementation :
> * as a user I have really no preference, I just want the feature
> * as a developer I played with both and for me these are just logg
@Benson
>No one, as far as I recall, objected, but perhaps my memory is selective.
just for the record: I did cast -1 on the commit and explained my objections ...
I
obviously don't like it but I wont 'veto' it as those technical
questions are simply majority votes. And there are quite some devs
Le samedi 1 décembre 2012 18:52:51 Dennis Lundberg a écrit :
> I would -1 any suggestion to start using the "beta" moniker again, at
> least for the changes made this far.
I completely agree
would it be more a milestone, to show the "stable but work in progress" state?
3.1.0-m1?
--
First off, thanks for an excellent summary Benson!
Comments inline...
On 2012-12-01 18:30, Benson Margulies wrote:
> I'm writing this to move the discussion about our next release off of
> a VOTE thread, where I don't think it belongs.
>
> Let me make a little historical summary. Jason and others
Although I generally stay away from any kind of logging-discussion
(and logging in general), I'd like to add my 0.5 NOK:
The version number *is* 3.1 due to this slight compatibility change;
we need to make this clear in release announcements to control
community expectations.
If a few plugins nee
I already have started a logback version, but I don't think this should affect
rolling the 3.1.0.
On Dec 1, 2012, at 6:57 AM, Arnaud Héritier wrote:
> I pushed the prototype developed by olivier using log4j2 in the
> branch feature/colorized-console/log4j2
> I updated with latest master changes
I'm writing this to move the discussion about our next release off of
a VOTE thread, where I don't think it belongs.
Let me make a little historical summary. Jason and others made a
series of significant changes to the core internals, including changes
to logging that some users of some plugins ma
I pushed the prototype developed by olivier using log4j2 in the
branch feature/colorized-console/log4j2
I updated with latest master changes
You can test the distro of this code : http://cl.ly/1B1z051O0T10
Tonight I'll try to do a logback version
cheers
Arnaud
On Sat, Dec 1, 2012 at 11:15 AM,
+1
Regards,
Hervé
Le mercredi 28 novembre 2012 11:03:06 Olivier Lamy a écrit :
> Hi,
>
> I'd like to release the archetype for maven plugin.
> The goal is to have an archetype which generate project using new mojo
> annotations (and a sample to run maven-invoker-plugin)
> We fixed 2 issues:
> h
I agree. That doesn't change that log4j2 is young compared to logback
and I could understand that people could prefer to select it over
log4j for that reason. Myself I have really no preference
The best I suppose will be to open a thread to discuss about pros and
cons of each ones and then vote. (
2012/12/1 Kristian Rosenvold :
> The maven-2 repos has been merged back into the official "maven" repo.
> Svn is still read/write but I will file a jira to make the svn url
> r/o.
>
maven-2 path just marked read only.
> The tags for releases pre 2.2.0 will have to be recreated by hand. I
> will do
2012/12/1 Gary Gregory :
> Log4j2 supports color consoles, even on Windows. Is this support
> incomplete? I know, I know,still in beta.
sometimes version naming doesn't have a real added value (IMHO)
some projects use 0.1.x model without any alpha/beta qualifier
some others use beta/alpha qualifie
Log4j2 supports color consoles, even on Windows. Is this support
incomplete? I know, I know,still in beta.
Gary
On Dec 1, 2012, at 5:05, Mark Struberg wrote:
> sounds great, have Oliviers branch running locally myself without issues.
>
> LieGrue,
> strub
>
>
>
>
> - Original Message -
>
On 1 Dec 2012, at 08:40, Hervé BOUTEMY wrote:
> I just created and fixed MNG-5395 and MNG-5396, which are logger names
> enhancements from the actual values that will give value even with slf4j-
> simple
>
> These should be a starting point for more global discussion about our logging
> convent
On 1 Dec 2012, at 10:07, Mark Struberg wrote:
> There is btw out of the box @InjectLogger support for Log4j2 in guice. A few
> projects are using this already without problems it seems.
Depends what you mean by 'out-of-the-box', Guice only provides built-in support
for @Inject of j.u.l.Logger
In that case the users cannot use plain slf4j APIs and we would not gain
anything anyway.
This would have the same effect like not exposing the classes in our core realm
at all.
LieGrue,
strub
>
> From: Arnaud Héritier
>To: Maven Developers List ; Mark Strube
+1
Op Fri, 30 Nov 2012 22:57:12 +0100 schreef Olivier Lamy :
my +1
2012/11/28 Olivier Lamy :
Hi,
I'd like to release the archetype for maven plugin.
The goal is to have an archetype which generate project using new mojo
annotations (and a sample to run maven-invoker-plugin)
We fixed 2 issues
+1
Op Thu, 29 Nov 2012 22:18:35 +0100 schreef Tony Chemit
:
On Wed, 28 Nov 2012 18:26:13 -0600
Paul Gier wrote:
+1 (nb)
works fine to me
thanks,
tony.
Hi,
We solved 10 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=18491
There are still a couple of
Couldn't we use the shading plugin to not expose the original
implementation (logback, log4k, whatever ..) but a repackaged one to avoid
conflicts with plugins which may bring (intentionally or by error) its own
impl ? ?
Perhaps my idea is just stupid ...
Arnaud
On Sat, Dec 1, 2012 at 11:02 AM,
On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY wrote:
> I just created and fixed MNG-5395 and MNG-5396, which are logger names
> enhancements from the actual values that will give value even with slf4j-
> simple
>
> These should be a starting point for more global discussion about our
> logging
>
Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
About the implementation :
* as a user I have really no preference, I just want the feature
* as a developer I played with both and for me these are just loggers
. We may organize a fight between Ceki and Ralph but it wo
There is btw out of the box @InjectLogger support for Log4j2 in guice. A few
projects are using this already without problems it seems.
LieGrue,
strub
- Original Message -
> From: Arnaud Héritier
> To: Maven Developers List
> Cc:
> Sent: Saturday, December 1, 2012 10:42 AM
> Subje
sounds great, have Oliviers branch running locally myself without issues.
LieGrue,
strub
- Original Message -
> From: Arnaud Héritier
> To: Maven Developers List
> Cc:
> Sent: Saturday, December 1, 2012 9:17 AM
> Subject: Re: Re-spinning 3.1.0
>
> Hi Jason,
>
> Couldn't we have
what is complex with say am openjpa enhancer mojo?
Still this will break depending what the project configures in it's
persistence.xml.
Just an idea for now:
The safe route might be a plugin-plugin annotatation which tells us 'plugin
uses slf4j' in that case it gets exposed, in other cases it do
I just created and fixed MNG-5395 and MNG-5396, which are logger names
enhancements from the actual values that will give value even with slf4j-
simple
These should be a starting point for more global discussion about our logging
conventions then fixed in our global codebase, since IMHO, these i
On Dec 1, 2012, at 12:17 AM, Arnaud Héritier wrote:
> Hi Jason,
>
> Couldn't we have a look at olamy's log4j2 branch to see if we could
> sanitize / merge it to propose at least one change for the end user
> and demonstrate the interest of the change about logs : a colorized
> console.
Not wi
Hi Jason,
Couldn't we have a look at olamy's log4j2 branch to see if we could
sanitize / merge it to propose at least one change for the end user
and demonstrate the interest of the change about logs : a colorized
console.
I remember you did that in mvnsh/teslashell a long time ago (as an
ext
65 matches
Mail list logo
