Le mardi 13 novembre 2012 10:09:51 Jason van Zyl a écrit :
> But again really, I believe the decision is to determine whether all this
> really necessary. I think the order of operations that folks think is
> reasonable is:
>
> 1) Get the release out with SLF4J
> 2) Determine whether we need loggi
On 12-11-12 9:29 AM, Olivier Lamy wrote:
2012/11/12 Igor Fedorenko :
On 12-11-11 6:52 PM, Olivier Lamy wrote:
If the discussion is now transitioning to users want flexible
logging and the choice of a logging framework that's fine. But I
still maintain the CLI use of logging can be limited
On Nov 12, 2012, at 9:21 AM, Olivier Lamy wrote:
>
> Currently I'm testing integrating jansi to have colorized output, that
> works fine and that's fun :-)
> Again I don't see why we couldn't add a bit or a possibility of fun
> within our distribution (or at least make that easily possible)
Sur
2012/11/12 Igor Fedorenko :
>
>
> On 12-11-11 6:52 PM, Olivier Lamy wrote:
>>>
>>> If the discussion is now transitioning to users want flexible
>>> logging and the choice of a logging framework that's fine. But I
>>> still maintain the CLI use of logging can be limited and
>>> constrained while al
2012/11/12 Jason van Zyl :
>
> On Nov 11, 2012, at 6:52 PM, Olivier Lamy wrote:
>
>> 2012/11/11 Jason van Zyl :
>>>
>>> On Nov 11, 2012, at 2:49 AM, Olivier Lamy wrote:
>>>
Perso I propose a change by pointing you (you means other maven dev
folks too) to a branch I made somewhere b
Release early, release often ;)
On Mon, Nov 12, 2012 at 2:04 PM, Jason van Zyl wrote:
> I think most agree that's a reasonable plan.
>
> On Nov 12, 2012, at 1:39 PM, Dennis Lundberg wrote:
>
> > I agree with Anders' proposal. Let us ship 3.1 of Maven using
> > slf4j-simple to get the change of
I think most agree that's a reasonable plan.
On Nov 12, 2012, at 1:39 PM, Dennis Lundberg wrote:
> I agree with Anders' proposal. Let us ship 3.1 of Maven using
> slf4j-simple to get the change of logging api properly tried in the field.
>
> After that, maybe targeting 3.2, we can discuss *if*
I agree with Anders' proposal. Let us ship 3.1 of Maven using
slf4j-simple to get the change of logging api properly tried in the field.
After that, maybe targeting 3.2, we can discuss *if* we need a complex
logging framework or not, and if so *which* framework would best suit
the needs that Maven
Greg,
After all these years I don't spend much time thinking about logging anymore. I
use SLF4J, Logback and contribute back to those projects if I need anything.
I see that 8-9 projects at Apache are already using Logback which I think is a
pretty good indicator.
At any rate, I think that we
Hi guys,
Hope ill not be too off topic but why not using slf4j-jdk? It is pretty
light since it relies on the jvm impl and it is already an interesting real
logging framework (with handler/appender, filter, level...)
Le 12 nov. 2012 16:20, "Jason van Zyl" a écrit :
> I responded in your dogfood
Jason,
That's all fine. I am looking for specifics to make Log4J 2 better.
Gary
On Mon, Nov 12, 2012 at 10:19 AM, Jason van Zyl wrote:
> Gary,
>
> If by that you mean that it's an Apache project, I don't consider that to
> be a significant criterion. For me to incorporate something it matters
I responded in your dogfood email.
On Nov 12, 2012, at 9:00 AM, Gary Gregory wrote:
> On Mon, Nov 12, 2012 at 8:17 AM, Jason van Zyl wrote:
>
>>
>> On Nov 11, 2012, at 6:52 PM, Olivier Lamy wrote:
>>
>>> 2012/11/11 Jason van Zyl :
On Nov 11, 2012, at 2:49 AM, Olivier Lamy wrote:
Gary,
If by that you mean that it's an Apache project, I don't consider that to be a
significant criterion. For me to incorporate something it matters that it's
technically good and has been vetted, is mature, is well supported and has a
community of users as that's how something gets vetted ov
On 12-11-11 6:52 PM, Olivier Lamy wrote:
If the discussion is now transitioning to users want flexible
logging and the choice of a logging framework that's fine. But I
still maintain the CLI use of logging can be limited and
constrained while allowing integrators to make the small changes
neces
On Mon, Nov 12, 2012 at 8:17 AM, Jason van Zyl wrote:
>
> On Nov 11, 2012, at 6:52 PM, Olivier Lamy wrote:
>
> > 2012/11/11 Jason van Zyl :
> >>
> >> On Nov 11, 2012, at 2:49 AM, Olivier Lamy wrote:
> >>
> >>>
> >>> Perso I propose a change by pointing you (you means other maven dev
> >>> folks
On Nov 11, 2012, at 6:52 PM, Olivier Lamy wrote:
> 2012/11/11 Jason van Zyl :
>>
>> On Nov 11, 2012, at 2:49 AM, Olivier Lamy wrote:
>>
>>>
>>> Perso I propose a change by pointing you (you means other maven dev
>>> folks too) to a branch I made somewhere but you commit code without
>>> list
2012/11/11 Jason van Zyl :
>
> On Nov 11, 2012, at 2:49 AM, Olivier Lamy wrote:
>
>>
>> Perso I propose a change by pointing you (you means other maven dev
>> folks too) to a branch I made somewhere but you commit code without
>> listening POV from others.
>> If you could wait to hear what other t
On Sun, Nov 11, 2012 at 7:59 AM, Jesse McConnell
wrote:
> On Sun, Nov 11, 2012 at 6:35 AM, Anders Hammar wrote:
>> Here's my suggestion:
>>
>> We keep the current state where we have the new logging API (slf4j) and the
>> System.out style implementation. Then we (Olivier?) create a JIRA ticket
>>
And then there is the whole eating your own dog food aspect of
choosing a logging framework. We've made some significant progress
over at log4j 2.0 and we are days from a beta3 release. It would be
nice to hear how we could further improve 2.0 to whet Maven's logging
appetite.
Gary
On Nov 11, 201
On Sun, Nov 11, 2012 at 6:35 AM, Anders Hammar wrote:
> Here's my suggestion:
>
> We keep the current state where we have the new logging API (slf4j) and the
> System.out style implementation. Then we (Olivier?) create a JIRA ticket
> for moving to a different logging implementation using a more f
yes, the question of which slf4j implementation we should use in Maven is a
different question from how to manage progress display during transfert.
And I like
> My goal was to
> introduce SLF4J in a minimal way, at least to start.
more than what I read previously, which gave me bad feeling witho
Here's my suggestion:
We keep the current state where we have the new logging API (slf4j) and the
System.out style implementation. Then we (Olivier?) create a JIRA ticket
for moving to a different logging implementation using a more flexible
logging framework. Then we discuss the benefits of doing
On Nov 11, 2012, at 2:49 AM, Olivier Lamy wrote:
>
> Perso I propose a change by pointing you (you means other maven dev
> folks too) to a branch I made somewhere but you commit code without
> listening POV from others.
> If you could wait to hear what other thinks that could be lovely
I b
2012/11/11 Jason van Zyl :
>
> On Nov 10, 2012, at 5:36 PM, Olivier Lamy wrote:
>
>> Hi,
>> As I daily use trunk as mvn version to work, I'm a bit irritate with
>> the current transfer listener :-)
>>
>
> Yes, I use Logback to do the same in integrations, but I would prefer not to
> pull in one o
On Nov 10, 2012, at 5:36 PM, Olivier Lamy wrote:
> Hi,
> As I daily use trunk as mvn version to work, I'm a bit irritate with
> the current transfer listener :-)
>
Yes, I use Logback to do the same in integrations, but I would prefer not to
pull in one of the larger frameworks simply to resol
Hi,
As I daily use trunk as mvn version to work, I'm a bit irritate with
the current transfer listener :-)
So I have fixed using log4j2 as slf4j implementation.
See the stuff here: https://github.com/olamy/maven-3/tree/log4j2
It's simply a matter of defining a different layout for transfer
logging
26 matches
Mail list logo
