Le lun. 4 mars 2024 à 10:49, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Note: this logging issue is not very important. If there is such
> resistance against it, I will not insist.
>
>
> Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit :
>
> > Please read
> >
> https://
Note: this logging issue is not very important. If there is such
resistance against it, I will not insist.
Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit :
Please read
https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html
I have already read that. The i
Martin
Please read
https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html
And "For the third time" we already have it
Also please stop this kind of statement "But System.Logger is the same
compromise and is as suitable as Log." this is nonsense to me since i
Le 2024-03-04 à 00 h 31, Pavel Horal a écrit :
isn't System.Logger mainly for JDK internals? I always thought that
using it is in a similar ballpark as using java.util.Optional in
method arguments (i.e. „please don’t“).
System.Logger was needed by JDK internal, e.g. because of bootstrapping
Hi,
sorry to jump into a conversation, but isn't System.Logger mainly for JDK
internals? I always thought that using it is in a similar ballpark as using
java.util.Optional in method arguments (i.e. „please don’t“).
Pavel
On Sun, 3 Mar 2024 at 23:54, Martin Desruisseaux <
martin.desruisse...@geo
Le 2024-03-03 à 22 h 53, Romain Manni-Bucau a écrit :
It is expected to use System so the logger finder. if it is not the
case you broke the contract of this API.
Can you point to the contract saying that?
As a matter of fact it is current state so not sure what you want to
enable.
For t
Le dim. 3 mars 2024 à 22:28, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-03-03 à 20 h 38, Romain Manni-Bucau a écrit :
>
> > the idea of maven-api was to abstract anything from the implementation
> > to be able to change
> A standard Java interface is as good as a M
Le 2024-03-03 à 20 h 38, Romain Manni-Bucau a écrit :
the idea of maven-api was to abstract anything from the implementation
to be able to change
A standard Java interface is as good as a Maven interface for that
purpose if they define equivalent methods, which is the case of
System.Logger ver
Le dim. 3 mars 2024 à 19:18, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit :
>
> >> (snip) Nothing force us to use System.getLogger() for getting an
> >> instance of that interface. (snip)
> >>
> > Yes but you make something
Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit :
(snip) Nothing force us to use System.getLogger() for getting an
instance of that interface. (snip)
Yes but you make something well specified misbehaving so while
technically true I think it would deserve us on the long run.
I do not und
Le dim. 3 mars 2024 à 17:50, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Hello Romain
>
> Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit :
>
> > SystemLogger has the ServiceLoader "pick random first" implementation
> > which is not what we want
> >
> You are describing
Hello Romain
Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit :
SystemLogger has the ServiceLoader "pick random first" implementation
which is not what we want
You are describing the behavior of the System.getLogger() method. I was
talking about the use of the System.Logger interface. Not
Hi,
I'm not sure I got what we would gain but here is my view on this topic:
* SystemLogger has the ServiceLoader "pick random first" implementation
which is not what we want I think and the API stays low level,
* If we want to drop Log we would rather go to JUL, which stays more
powerful in term
Ok, think the thread starts to fork (;)).
On the "is JUL a bad API" point: to day it is close to concurrent and
likely equivalent on a pure technical point of view - keep in mind we now
have supplier which makes {} legacy and worse than concatenation most of
the times. Only thing it misses is prob
On 6/11/2022 at 8:48:28 PM, Ralph Goers wrote:
> But the biggest problems with JUL include requiring everything being
> wrapped with isEnabled type methods to avoid logging overhead
I believe that was one of things addressed in the Flogger benefits - with
their API using LOG.atDebug()... or LO
Yes, I am aware of Flogger. Both the Log4j and SLF4J APIs now also have
fluent methods for those that prefer them. But the biggest problems with JUL
include requiring everything being wrapped with isEnabled type methods to
avoid logging overhead, an extremely limited set of Handlers, extremely
On 6/11/2022 at 8:31:45 PM, Ralph Goers wrote:
> I can absolutely guarantee you that if Google is actually using JUL that
> they
> have written plenty of their own code on top of it since JUL is woefully
> incomplete.
Google came up with Flogger - their fluent logging API that wraps JUL ( and
> On Nov 5, 2022, at 6:08 AM, Elliotte Rusty Harold wrote:
>
> After log4shell last year, I no longer have any patience for third
> party logging libraries, full stop.
>
> IMO logging should be done through java.util.logging, nothing else.
> This is fully functional since Java 1.4 twenty year
Please take in consider that this topic is not about
- changing logging in Maven ecosystem,
- using or not third party library
If you feel that is needed please start a separate thread about it.
sob., 5 lis 2022 o 19:34 Elliotte Rusty Harold
napisał(a):
> You're right that I might as well be
You're right that I might as well be talking about all third party
libraries. In fact, I've said exactly that elsewhere, most recently at
ApacheCon a month ago and also here:
https://jlbp.dev/JLBP-1
The difference is only that we really, really don't need to take the
risk for logging libraries wh
Le sam. 5 nov. 2022 à 19:03, Gary Gregory a écrit :
> On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold
> wrote:
>
> > After log4shell last year, I no longer have any patience for third
> > party logging libraries, full stop.
> >
>
> Uh? CVEs have occurred in all types of libraries, there is noth
On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold wrote:
> After log4shell last year, I no longer have any patience for third
> party logging libraries, full stop.
>
Uh? CVEs have occurred in all types of libraries, there is nothing about
logging that makes it more CVE-prone. You might as well be
After log4shell last year, I no longer have any patience for third
party logging libraries, full stop.
IMO logging should be done through java.util.logging, nothing else.
This is fully functional since Java 1.4 twenty years ago. Log4j,
slf4j, plexus-logging, etc. are all efforts to solve a problem
> Maven Plugin code should use Plugin Api for logging purpose
> In shared libraries used by Maven and maintained by us - we will use
SLF4J directly
I asked to be allowed to put this on the logging site, but we never had
consensus of this. I agree 💯 here, but ut really needs to get documented.
I sa
Agree for option (disagree it is not common but that's not important) just
because there is no real choice else we would need to handle all libraries
and all versions which is clearly a no go for me.
Just a side note on the shared code: fully agree until log is exposed in
the API and can be reused
Once again thanks for feedback.
In order to finish discussion and not return to this topic again I will try
to update documentation about logging in Maven plugins ... so I see the
message, as Tamás wrote
- Maven core and ecosystem uses SLF4J.
- Maven Plugin code should use Plugin Api for logging
> perfectly valid solution (classloader)
This is a workaround any plugin developer hates to be honest.
Guillaume started to make the plugin ClassRealm more customizable, this can
be an option but still, means we don't leak slf4j.
I fully agree the issue is how we expose it to plugins and extension
So, you see problems in some plugins (again, what is the ratio we speak
about?)
using some frameworks, and then you tell the perfectly valid solution
(classloader)...
And regarding slf4j, should I reiterate what Ceki repeated several times?
Sorry, but these are non-issues IMHO.
Or to rephrase: w
Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák a écrit :
> Howdy,
>
> Will we keep asking the same questions over and over again? Until we get
> the "wanted" answer?
>
> Maven core and ecosystem uses SLF4J API. Full stop.
>
> Just use SLF4J API, and you will get a pre-configured back-end as well.
>
Howdy,
Will we keep asking the same questions over and over again? Until we get
the "wanted" answer?
Maven core and ecosystem uses SLF4J API. Full stop.
Just use SLF4J API, and you will get a pre-configured back-end as well.
Done.
Now,. this story keeps popping up: "plugin developers using fram
Hi,
+1 for JUL, it is the most portable and less intrusive solution since it is
built-in, graalvm friendly (mvnd) and any backend compatible (slf4j,
logback directly, log4j2, ...).
It is always a pity for a solution which can embedded user code -
mojo/extensions - to force a logging library IMHO s
And let's not forget that Log4j also is a facade API:
https://logging.apache.org/log4j/2.x/manual/api-separation.html
Gary
On Fri, Nov 4, 2022, 06:56 Slawomir Jaranowski
wrote:
> Hi,
>
> I want to start ( again :-) ) a discussion about logging in Maven plugins.
>
> First I agree that plugin de
https://maven.apache.org/maven-logging.html needs to be updated,
but also some plugins where changes were already made.
This was from slack: https://issues.apache.org/jira/browse/MNG-6931
And plugins pulling in slf4j directly happen all the time:
https://github.com/apache/maven-artifact-plugin/pu
I agree that we should advice that Maven Plugins should use the provided
logging API.
I can't find the ticket anymore, but I've created one where it should be
possible to scope the debug-logging for a specific goal.
Most of the time you're interested in the debug logging of the last failed goal
Hi
+1 to explicit it.
About message formatting it is not critical for me and enables to switch
the impl at will without being impl locked so maybe rather add lazy
evaluation with lambdas like in jul.
Le dim. 17 janv. 2021 à 22:42, Slawomir Jaranowski
a écrit :
> Hi,
>
> For developers logging
pon., 2 gru 2019 o 09:52 Jochen Wiedmann
napisał(a):
> On Thu, Nov 28, 2019 at 9:46 PM Slawomir Jaranowski
> wrote:
>
> > I'm writing some maven plugins - some for fun and with public code but
> more
> > maven plugins I'm writing for job in my company.
> >
> > Maven from version 3.1.x use slf4j
On Thu, Nov 28, 2019 at 9:46 PM Slawomir Jaranowski
wrote:
> I'm writing some maven plugins - some for fun and with public code but more
> maven plugins I'm writing for job in my company.
>
> Maven from version 3.1.x use slf4j for logging.
>
> But plugin api still use simple logging api
> org.apa
From: Jason Pyeron
Sent: Wednesday, November 23, 2016 2:59 PM
To: dev@maven.apache.org
Subject: Logging for 3.0.x and >=3.1.0
Working on a plugin right now and it needs to work in 3.0 as well as 3.3.
Scratching my head on can we use slf4j in 3.0 or is there a b
lto:i...@ifedorenko.com]
> > Sent: Tuesday, June 09, 2015 12:15
> > To: Maven Developers List; Sander Verhagen
> > Subject: Re: logging during multithreaded builds (follow-up)
> >
> > Based on the feedback I got on this list I did not include the logger
> > extensi
pdate your
address book. Thank you!
> -Original Message-
> From: Igor Fedorenko [mailto:i...@ifedorenko.com]
> Sent: Tuesday, June 09, 2015 12:15
> To: Maven Developers List; Sander Verhagen
> Subject: Re: logging during multithreaded builds (follow-up)
>
> Based on
Based on the feedback I got on this list I did not include the logger
extension in maven itself but kept it in a separate repository. I may
opensource that repository some time in the future but it is not a priority
for me right now.
--
Regards,
Igor
On June 9, 2015 1:33:46 PM Sander Verhag
I know it's not directly related, but any general purpose algorithm that
captures to memory buffers needs an overflow to disk mechanism - every time
a ByteArrayOutputStream is used for this, some guy with a *huge* output
from his build gets an OOM.
It's nice you're looking into this issue. As for
I agree with Jason, it would be better to keep this outside of core (the
core distro).
/Anders
On Thu, May 28, 2015 at 5:21 AM, Jason van Zyl wrote:
> I honestly don't think an optional feature relying on an optional
> dependency belongs in the core itself.
>
> On May 27, 2015, at 10:34 PM, Igo
I honestly don't think an optional feature relying on an optional dependency
belongs in the core itself.
On May 27, 2015, at 10:34 PM, Igor Fedorenko wrote:
> There are three semi-related parts to my implementation
>
> 1. SLF4J MDC management, basically setting and removing project
> attribute
There are three semi-related parts to my implementation
1. SLF4J MDC management, basically setting and removing project
attributes in a thread-local map. Truly reliable implementation will
need to be coded in all Builders. Alternatively, it should be possible
to use existing lifecycle callbacks to
On May 27, 2015, at 3:55 PM, Igor Fedorenko wrote:
> So I went ahead and implemented these changes, including working (but
> not terribly well tested) logback appenders to buffer-and-group project
> console log messages and create per-project build.log files.
>
What changes were required in t
So I went ahead and implemented these changes, including working (but
not terribly well tested) logback appenders to buffer-and-group project
console log messages and create per-project build.log files.
Does anyone see a problem if I check in these appenders in maven core
source tree or you prefe
I spent some time looking into this, and I think project-level logging
will require several semi-related changes.
* As Ralph pointed out, Maven needs to use SLF4J MDC to associate log
messages with individual projects being built. This is required to
enable any project-related logging approach and
If you use the SLF4J MDC - which is supported by Logback, Log4j 1.x and 2.x -
you can include anything stored in the MDC on every line of log output. Just
use %X to include all MDC items or %MDC{key} to include the specific key. This
would require storing the value(s) at the beginning of every
Igor Fedorenko wrote on 05/25/2015 07:28:45 AM:
> I had to troubleshoot a large multithreaded build last week and that
> proved to be rather difficult mostly because build log was a jumble of
> messages produced by concurrently running threads. It was not possible
> to tell which message came fro
Yes, thread-id will help to some degree, but maven uses multiline log
messages quite often and these will still be mangled and unreadable.
Per-project build log files is the only solution I found to preserve
readable logs. Also, each project build is mostly independent from the
rest and I find read
In multithreaded builds we could add a thread ID to each output line. That
would make it easier to read and filter in different files in post
processing.
--
Sean
On May 25, 2015 6:30 AM, "Igor Fedorenko" wrote:
> I had to troubleshoot a large multithreaded build last week and that
> proved to b
Hello,
you need to escape : and \ in properties files:
org.slf4j.simpleLogger.logFile=E\:\\Mavenlogs\\Mavenlog.txt
BTW: this is a maven users question.
Gruss
Bernd
Am Thu, 20 Nov 2014 14:37:08 +
schrieb "Held, James E." :
> We'd like to log all maven activity to one common place by chan
On Mon, Jan 7, 2013 at 2:07 PM, Jason van Zyl wrote:
> That's all reasonable. I will take silence from the rest as tacit
> agreement.
>
+1 to spoil the tacit silence.
>
> On Jan 7, 2013, at 1:33 PM, Dennis Lundberg wrote:
>
> > Hi Jason
> >
> > From what I have gathered from these discussions
That's all reasonable. I will take silence from the rest as tacit agreement.
On Jan 7, 2013, at 1:33 PM, Dennis Lundberg wrote:
> Hi Jason
>
> From what I have gathered from these discussions, we have a majority of
> people that want to stick with SLF4J Simple for the 3.1.0 release, if
> all th
Hi Jason
>From what I have gathered from these discussions, we have a majority of
people that want to stick with SLF4J Simple for the 3.1.0 release, if
all the quirks are ironed out. Judging by Hervé's recent commits this is
almost done, except for the class loading isolation in MNG-5406.
I think
I believe this is sufficient provided that we agree when any one attempts to
select the logging framework that there is a discussion.
As I see it I have been blocked as the person doing the work from selecting the
implementation I would like because of a rule against EPL dependencies which
was
yes, I'm stuck with classloader isolation MNG-5406
I don't see how to add a classworlds rule to do that
if you can help me find the proper way to to it, it would be nice, please
Regards,
Hervé
Le dimanche 6 janvier 2013 08:44:25 Jason van Zyl a écrit :
> Cool, do you still need help with the cla
Cool, do you still need help with the classloader isolation? If not I'll move
on to the Aether work.
On Jan 6, 2013, at 5:52 AM, Hervé BOUTEMY wrote:
> done in 72bdc8602e5112aa273adc46b06d41c41f0f64a8
>
> resetting slf4j factory wasn't sufficient: needed to so the same for slf4j-
> simple, wit
done in 72bdc8602e5112aa273adc46b06d41c41f0f64a8
resetting slf4j factory wasn't sufficient: needed to so the same for slf4j-
simple, with same technique
Core ITs now run on my machine: great!
Regards,
Hervé
Le mercredi 2 janvier 2013 08:20:12 Hervé BOUTEMY a écrit :
> yes, Maven isn't an app s
yes, Maven isn't an app server, strict security manager shouldn't be an issue:
if someone knows of a situation where it would be, please tell it :)
the very good news with this solution is that it is at slf4j-api level, not
dependent on logging implementation!
I'll look at it in the WE, if nobo
It is. You create that package structure in your app to access it.
jvz
On 2013-01-01, at 8:48 PM, Stephen Connolly
wrote:
> If I read that right it is accessing a package local method...
>
> That won't work with a security manager in play (not that we have one)
> [unless we repackage the api
If I read that right it is accessing a package local method...
That won't work with a security manager in play (not that we have one)
[unless we repackage the api jar] but just wondering if that may affect
embedded use?
On Tuesday, 1 January 2013, Jason van Zyl wrote:
>
> On Jan 1, 2013, at 6:15
On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY wrote:
> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
>> If we want to put aside the debate, Ceki has figured out a way for use SLF4J
>> Simple by resetting the streams and logging level. Which I can try if we
>> want to go down that path.
Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
> If we want to put aside the debate, Ceki has figured out a way for use SLF4J
> Simple by resetting the streams and logging level. Which I can try if we
> want to go down that path. I didn't have to do any work in SLF4J myself so
> I'm fin
Hi,
If SLF4J Simple is now a viable option again, i.e. the problems reported
with concurrency and embedding has been sorted out, then that is the
obvious choice to me.
On 2012-12-24 15:12, Jason van Zyl wrote:
> I'm going to push this along and I agree with Stephen insofar as if you
> prefer an
I will try out Ceki's suggestion early next week and report back.
On Dec 24, 2012, at 11:58 AM, Stephen Connolly
wrote:
> Yep if simple is back on the table commit that and let the fight be
> resolved later.
>
> This logback vs log4j2 debate seems fractious to try and resolve right now
> so st
Yep if simple is back on the table commit that and let the fight be
resolved later.
This logback vs log4j2 debate seems fractious to try and resolve right now
so sticking to your original plan of the *non-choice* that is simple will
allow moving forward (though with some cribbing and moaning from
On Mon, Dec 24, 2012 at 9:12 AM, Jason van Zyl wrote:
> I'm going to push this along and I agree with Stephen insofar as if you
> prefer an implementation then there should be a branch to support that
> preference. Thus far I have not seen anything aside from Stephen's efforts
> which are a PoC
I'm going to push this along and I agree with Stephen insofar as if you prefer
an implementation then there should be a branch to support that preference.
Thus far I have not seen anything aside from Stephen's efforts which are a PoC
so the choice is between SLF4J Simple, Logback and Log4J2.
If
I'll get it up on our Jenkins but here's a run that shows it passes:
http://ci.tesla.io:8080/job/maven-its-logback/jdk=jdk-1.6/20/
On Dec 17, 2012, at 12:35 PM, Stephen Connolly
wrote:
> On 17 December 2012 17:28, Olivier Lamy wrote:
>
>> 2012/12/17 Stephen Connolly :
>>> Now the above could
Yup, the logback stuff all passes. The grid has been a bit wonky but I'll put a
job up there.
On Dec 17, 2012, at 12:35 PM, Stephen Connolly
wrote:
> On 17 December 2012 17:28, Olivier Lamy wrote:
>
>> 2012/12/17 Stephen Connolly :
>>> Now the above could be fixed... but *somebody* needs to
On Mon, Dec 17, 2012 at 9:46 AM, Olivier Lamy wrote:
> And what about working on real improvements for users ?
I don't follow. I sent an email that attempts to bring this debate to
a close so that, in fact, we can get a release out and get on with
other projects, of which all of the below are goo
Which, from my point of view, proves our failure.
A user should never have to use maven in debug to understand its project
dependencies.
dependency:tree, list, analyze should be our first calls mojo to help users
to sanitize their dependencies and to better understand the how maven is
doing the res
Personally I find "-X dependency:tree" -way- more useful. Half the time
when I'm trying to track down dependency problems maven itself fails to
fully resolve dependencies and crashes out the mojo without displaying
anything useful, so you end up looking though the debug information to
find whi
On 17 December 2012 17:28, Olivier Lamy wrote:
> 2012/12/17 Stephen Connolly :
> > Now the above could be fixed... but *somebody* needs to write some code
> to
> > make them fixed. In the absence of anyone writing such code and
> committing
> > it, those branches are dead... as are those choices.
raded maven-plugin-plugin build.
>>
>
> I smell FUD again. My understanding is Hervé is working on the solution to
> that.
>
>
>>
>>
>> And most of the log output in projects (surefire) will still funneled via
>> a stdio redirecting, so all the benefit is
he benefit is lost for them, isn't?
>
Have you run with -X recently?
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: Stephen Connolly
> > To: Maven Developers List
> > Cc:
> > Sent: Monday, December 17, 2012 3:58 PM
nday, December 17, 2012 3:58 PM
> Subject: Re: Logging
>
> On 17 December 2012 14:46, Olivier Lamy wrote:
>
>> And what about working on real improvements for users ?
>>
>> I see:
>> * incremental build
>> * fixing various bugs on depen
On 17 December 2012 14:46, Olivier Lamy wrote:
> And what about working on real improvements for users ?
>
> I see:
> * incremental build
> * fixing various bugs on dependency plugin (tree doesn't work well
> since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
> old one (https://
+100
i really think "maven is bad" sentences we sometimes hear doesn't
reference the logging at all so probably not something where time
should be lost
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github:
And what about working on real improvements for users ?
I see:
* incremental build
* fixing various bugs on dependency plugin (tree doesn't work well
since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
votes. And IM
Great summary Benson, I agree with your assessments here.
On Sun, Dec 16, 2012 at 12:16 PM, Benson Margulies wrote:
> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how
I was just giving folks time to make their branches and evaluate. For people
who felt strongly like Olviier and myself I expect them to make branches and
implement something for comparison.
I didn't want to do anymore work on SLF4J Simple but Ceki is going to implement
a reset function in the l
On Sun, Dec 16, 2012 at 12:16 PM, Benson Margulies wrote:
> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how close we are to a consensus.
>
> In the following, I use th
Since not much has been heard on the 'pick a logger' question for some
time, I'm going to stick my neck out and try to summarize some
aspects, in the hopes of discovering how close we are to a consensus.
In the following, I use the word 'want' to express *preference*, not
non-negotiable demands.
On Dec 10, 2012, at 3:46 PM, John Casey wrote:
> On 12/10/12 2:42 PM, Jason van Zyl wrote:
>> It would be the default backend, people would not be using Logback APIs
>> directly.
>>
>> The one place where it's convenient for use the use the Logback APIs is in
>> the CLI where it's not possibl
On 12/10/12 2:42 PM, Jason van Zyl wrote:
It would be the default backend, people would not be using Logback APIs
directly.
The one place where it's convenient for use the use the Logback APIs is in the
CLI where it's not possible to change the log levels without talking directly
to the imple
Looking at Drools Guvnor, it's ASL...as is the rest of Drools.
And I believe the code they were asking about was related to some new
features in Guvnor...
So, I guess I'm at a loss for what Mark's concern was. It's still an
issue for GPL projects, but I haven't had that come up yet.
Underst
It would be the default backend, people would not be using Logback APIs
directly.
The one place where it's convenient for use the use the Logback APIs is in the
CLI where it's not possible to change the log levels without talking directly
to the implementation.
On Dec 10, 2012, at 3:40 PM, Joh
Reading through the rest of the thread...is this for the default
implementation we'll ship with maven, or are we talking about skipping
the slf4j-api abstraction and using logback apis directly?
If it's just the default backend, I'm not concerned at all. If we're
forcing people to use logback,
On 12/10/12 2:25 PM, Jason van Zyl wrote:
John,
Eight other projects at Apache use Logback.
The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems
with the EPL. I don't think JBoss would ship a huge product entirely based on
EPL if there were a problem.
Oracle also n
John,
Eight other projects at Apache use Logback.
The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems
with the EPL. I don't think JBoss would ship a huge product entirely based on
EPL if there were a problem.
Oracle also now accepts EPL dependencies in their produc
On 12/9/12 7:50 PM, Jason van Zyl wrote:
I think it's time to stop patching SLF4J Simple. I have an inefficient fix for
the embedding problem, but we're likely to run into issues concurrency with
parallel builds and who knows what else. This will patch/change #5 and many
hours of trying to get
I cannot
content is here
https://svn.apache.org/repos/infra/websites/production/maven/content/
just need to be checkout a first time.
As some asked to have documentation for plugins for each version we
have a lot of content.
So need some time, so tea time for me.
2012/12/10 Jason van Zyl :
> Maybe
Maybe you can copy over the index.html we can prevent the directory listing
from showing up on our home page.
On Dec 10, 2012, at 10:03 AM, Olivier Lamy wrote:
> http://markmail.org/message/mpgn4yshnt2qmdui
>
> 2012/12/10 Jason van Zyl :
>> Not sure what's happening but:
>>
>> http://maven.ap
http://markmail.org/message/mpgn4yshnt2qmdui
2012/12/10 Jason van Zyl :
> Not sure what's happening but:
>
> http://maven.apache.org/developers/dependency-policies.html
>
> is not there.
>
> On Dec 10, 2012, at 3:25 AM, Olivier Lamy wrote:
>
>> 2012/12/10 Hervé BOUTEMY :
>>> Le dimanche 9 décembr
Not sure what's happening but:
http://maven.apache.org/developers/dependency-policies.html
is not there.
On Dec 10, 2012, at 3:25 AM, Olivier Lamy wrote:
> 2012/12/10 Hervé BOUTEMY :
>> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>> I think it's time to stop patching SLF4J Si
been?
>
>
> LieGrue,
> strub
>
>
>
> - Original Message -
>> From: Jason van Zyl
>> To: Maven Developers List
>> Cc:
>> Sent: Monday, December 10, 2012 8:33 AM
>> Subject: Re: Logging
>>
>>
>> On Dec 10, 201
Curious...reading through all of this it seems there are two primary
situations in play I was wondering if the 'default' logging for console and
embedded need to be so strictly aligned and if you could not just also
publish an distribution or aggregation specifically for embedded that
contains a mo
1 - 100 of 141 matches
Mail list logo
