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 :
>
>
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
doc saying that we should not use it." - cause
you don't care about the issue maven api solves for now.
So there is no real way we do it, as I repeated 3 times, cause the key is
not the API.
Also "Maven, which need more than println but not as much as a real logging
framework"
more than println but not as much as a real
logging framework.
Martin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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
providing useful "source class" and "source method"
> information. That is the issue. I'm not sure what a "Maven bridge" is,
> but if it is some kind of wrappers, this is an extra complexity which
> need to be justified by extra features. In the current Ma
is some kind of wrappers, this is an extra complexity which
need to be justified by extra features. In the current Maven Log
interface, there is no such extra features except slightly more compact
method calls (logging levels as method names instead of a method parameter).
I'm not sure w
ding JUL it is used.
>
>
> >> I did not talked about performance, but about misleading information
> >> filled in log record (snip).
> >
> > For me it means a bug in the implementation
> >
> It is not a bug. When a logger uses stackwalker for determining
that Log would become System.Logger.
Where do you see a misbehaviour?
I did not talked about performance, but about misleading information
filled in log record (snip).
For me it means a bug in the implementation
It is not a bug. When a logger uses stackwalker for determining who is
logging
> powerful in terms of API, usable in terms of implementation and still
> > as pluggable as SystemLogger for a runtime like maven.
> >
> Yes, I also prefer java.util.logging. I proposed System.Logger because
> it has a one-to-one match with the current Maven Log (except in the way
PI, usable in terms of implementation and still
as pluggable as SystemLogger for a runtime like maven.
Yes, I also prefer java.util.logging. I proposed System.Logger because
it has a one-to-one match with the current Maven Log (except in the way
to specify the logging level). It is also les
I tend to agree with your point about N records (N>1) vs 1 record but
this is independent of all log API you mentionned, we can fix it with maven
old log api, the new one, java or anything, it is a caller thing - but more
than agree we should stop logging lines but think records.
Guess I got y
keep the Maven `Log` interface as a wrapper around
`System.Logger` for convenience. However, some logging implementations
such as `java.util.logging` use Java reflection for detecting the caller
class and method. If we keep the Maven `Log` as a convenience instead of
direct use of `System.Logger`,
Le ven. 24 févr. 2023 à 17:31, Delany a écrit :
> I turned on -e as default last month and had to turn it off again.
> When a change causes a group of tests to fail I get the stack trace for
> each test failure first up in the project and then repeated as the cause of
> the reactor failing.
> I d
I turned on -e as default last month and had to turn it off again.
When a change causes a group of tests to fail I get the stack trace for
each test failure first up in the project and then repeated as the cause of
the reactor failing.
I don't mind it on by default, but then how do I turn it off?
+1 for -e default
From: Romain Manni-Bucau
Sent: Friday, February 24, 2023 9:15:15 PM
To: Maven Developers List
Subject: Re: And while I'm on the subject of logging
Hi Elliotte,
I agree -e should be the default, I don't see the point to not have the
e
Hi Elliotte,
I agree -e should be the default, I don't see the point to not have the
error cause when it fails.
Your point 2 is only relevant if you never built the project nor a project
with the same dependencies so I guess we can assume it is a corner case - I
was also often checkouting projects
Hi Elliot,
did you try to use mvnDebug?
> Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold :
>
> Real world example from the non-Apache project built with Maven I'm
> working on this morning.
>
> 1. Build fails
> 2. 591 lines of log output in my console, almost all of which are
> artifacts
Real world example from the non-Apache project built with Maven I'm
working on this morning.
1. Build fails
2. 591 lines of log output in my console, almost all of which are
artifacts being downloaded.
3. Relevant lines: 1
4. Percentage useful content: .17%
That's bad. But wait. It gets worse.
T
In the spirit of your elephant analogy, what is deserving of INFO level
logging?
On Thu, 23 Feb 2023 at 14:11, Elliotte Rusty Harold
wrote:
> On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
> wrote:
> >
> > Eliotte I kind of fail to follow your reasoning because it
> downloading logs really help there when you can keep them.
>
> Again, that is *NOT* what I am saying. I think that network issues are
> a real problem which is why I want them to be much easier to find and
> debug by not logging things that aren't problems.
>
> --
>
y I want them to be much easier to find and
debug by not logging things that aren't problems.
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
you can add a config or parameter to do this.
BUT I need that log, please don't remove it
From: Kemal Soysal
Sent: Thursday, February 23, 2023 5:39:08 PM
To: Maven Developers List
Subject: Re: And while I'm on the subject of logging
+1 logback
>
alph Goers a
> écrit :
>
>> Might I suggest that you are never going to make everyone happy. That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to lo
-1 to switch to logback or log4j (in particular v2 which is still slow and
fatty).
Think what we need is a good system prop config, can be achieved with jul
(ex: https://www.yupiik.io/yupiik-logging/jul-integration.html).
What I like with mvnd is not logback but the jansi/terminal usage which
I wrote much of
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
20 years back, and still stand by the basic message.
Maven is a build tool though, and aims and reproducibility. Minimal output
should be the default (console and log files). If so
t; why Logging frameworks such as Log4j support using Logger names, Log
> Levels, and Markers as basic ways of categorizing log events. With those
> you can continue to log events but filter them down to just what the user
> wants.
>
> Unfortunately, doing this will tie you to a logg
Might I suggest that you are never going to make everyone happy. That is why
Logging frameworks such as Log4j support using Logger names, Log Levels, and
Markers as basic ways of categorizing log events. With those you can continue
to log events but filter them down to just what the user wants
ld do,
> tell me when something unusual happens, like when something is taking a
> long time. For us Windows users, the Explorer UI only pops up its progress
> dialog when you are copying "a lot" or its taking "a long time", otherwise
> it is quiet.
>
> Question: when
", otherwise
it is quiet.
Question: when I ask mvn for -U behavior, I do like to see the download
logging, because I am asking for non-default behavior, I expect the extra
output.
As previously mentioned, there won't be change that makes everyone happy,
but IMO, there should be values I
Another example of excessive logging prompting one to find the root cause:
On Mon, 6 Feb 2023 at 15:03, James Agnew wrote:
> Just to close the loop in case anyone finds this post.
>
> I had discounted the idea that a version range was the cause because I went
> over all of th
You're arguing based on principles, but my experience suggests otherwise.
Some real life examples:
https://issues.apache.org/jira/browse/MENFORCER-462
https://issues.apache.org/jira/browse/MNG-7214
I would not have noticed or logged either of these issues without logging.
Its because they
The logging discussion is well underway.
According to my experience with build management,
there has always been these contradicting requirements no logging to heaps of
more logging in case of an error.
If the build seemed to run smoothly you were fooled by everything looking fine,
unless you
I do agree that logging all downloads is unneeded, and I do agree that the
hanging case can happen quite often and one needs to be informed.
However, both goals are not conflicting, we just need to enhance the
logger/downloader to:
* print a single statement that it starts downloading things
ktpub.com/application-development/java-ee-8-high-performance>
Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold a
écrit :
> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> wrote:
> >
> >
> > except there is no issue, the download is just slow so why would
On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
wrote:
>
>
> except there is no issue, the download is just slow so why would you
> fail?
> Hapoy to discuss a better solution but logging is a very satisfying one.
If there is no issue, don't log it. If being slow is a
blesome one when
> it
> > fails or hangs and not logging anything means maven hangs for end user
> > without idea why until you kill -3 it which is often hard on CI so think
> > "downloading" info is key there, similarly "downloaded" enables to know
> an
> &g
On Tue, Feb 21, 2023 at 3:07 PM Romain Manni-Bucau
wrote:
> In terms of default I think default should match the most common case and
> downloads is not a common case for maven but a very troublesome one when it
> fails or hangs and not logging anything means maven hangs for end user
t you
need and relevant.
In terms of default I think default should match the most common case and
downloads is not a common case for maven but a very troublesome one when it
fails or hangs and not logging anything means maven hangs for end user
without idea why until you kill -3 it which is often
t verbosity message maybe even just
print the following:
Building my.project:module1:123 ...
Building my.project:module2:345 ...
Building my.project:module3:345 ...
Build success!
Am 21.02.23 um 19:59 schrieb Elliotte Rusty Harold:
A general pattern I notice in discussions of excessive l
A general pattern I notice in discussions of excessive logging — not
just here and not only involving Maven — is to describe a scenario in
which a certain log message is useful. This is not hard to do but does
not justify the log message. Instead it is necessary to estimate how
often that log
l. On StackOverflow
questions like "Why is Maven downloading ...?"[1]
If I might add my 2 cents, the right amount of logging should:
1. allow people with 56 Kbps connections to understand why the build
is taking ages,
2. inform the other users (that set -ntp), what does Maven download an
I wouldn't miss a thing past line 2. Since its all ERROR I have no control
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile
(default-compile) on project error_prone_core: Compilation failure
[ERROR]
/git/error-prone/core/src/main/java/com/google/errorpro
uide on
common errors.
Current logs helped several times, are only logged on downloads (almost
never on a well setup build) and we have flags to drop them at need so I'd
rather chase actual issues like interleaving or optimise the "ui" like mvnd
did than dropping info which has its p
On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
wrote:
>
> Do you want to make maven output only SUCCESS or FAILURE? All default info
> logs are close to these download logs in practise.
>
Not always, but it should be far less verbose than it is now. It is an
oft forgotten principle of TDD th
Do you want to make maven output only SUCCESS or FAILURE? All default info
logs are close to these download logs in practise.
I think they are helpful, can agree with you on "not always" but having to
debug each time is worse than having to debug once from time to time so the
trade off is not bad.
On Mon, Feb 20, 2023 at 8:19 PM Romain Manni-Bucau
wrote:
>
> except that if you dont have it when you need (default) you have no
> solution
In my experience, about half the time when I do need a log message it
still isn't there. I have to use a debugger, packet inspection, or
some other tec
eed is
> somewhere in a very long stream of text that is challenging to search
> through or the information I need is in fact not logged at all and I
> have to use other methods to find out what's happening. Gratuitous,
> verbose logging has very little use.
>
It is why I said w
ning. Gratuitous,
verbose logging has very little use.
On Mon, Feb 20, 2023 at 3:02 PM Romain Manni-Bucau
wrote:
>
> Hi,
>
> I think the value of these lines are to know a download is pending (so
> downloading line is key more than knowing it got downloaded which means
> everythi
I care to be able to see what is downloaded, and it makes sense to see when
an attempt is started and when it succeeds.
I don't care how big it is (I can find that out myself) or how fast its
pulled down (meaningless since parallel downloads).
When I don't want to see it I manipulate the simple log
nk we really have 2 steps:
1. make it all fully configurable (guess we all want to avoid any new CLI
option for such a thing and just use logger and --logging-level?)
2. define the default: here I think we should be iso of today state or go
to something like "downloading..." for the *phase* (n
Maybe then one would remove that logging at all, and use different
"logging plugin extensions" :-)
Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case i
Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values
Well you can just reduce it to a single '.' who cares WHAT is download
and where it is placed and from where... now put a line break after say
50 dots
Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
Howdy,
completely agree, the default could be something along those lines:
[DL] central
https:
Howdy,
completely agree, the default could be something along those lines:
[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
So something like
[DL|UP] $repoId $artifactUrl
Full URL is handy as one can click on it in Terminal.app. But
redundant
Typical log message in build:
Downloaded from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)
I have never, ever needed or wanted to know how fast a single artifact
was downloaded. And in the extremely unlikely event I cared ho
; issue you mention, as now listener emits two
> > (mutually exclusive) events only:
> > - transfer succeeded
> > - transfer failed
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 1:55 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
ed
>
> T
>
> On Mon, Feb 20, 2023 at 1:55 PM Romain Manni-Bucau
> wrote:
>
> > Hi,
> >
> > Doesn't it move the issue to the "next event"? Guess it should be fully
> > customizable or not at all.
> > Also it keeps the logging in
at 1:55 PM Romain Manni-Bucau
wrote:
> Hi,
>
> Doesn't it move the issue to the "next event"? Guess it should be fully
> customizable or not at all.
> Also it keeps the logging interleaving issue - this is why the logger
> solution sounded neat to me.
>
> Romai
Hi,
Doesn't it move the issue to the "next event"? Guess it should be fully
customizable or not at all.
Also it keeps the logging interleaving issue - this is why the logger
solution sounded neat to me.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibuc
Created this PR as "experiment":
https://github.com/apache/maven/pull/1003
It will produce "nearly" the upcoming Maven 3.9.1 and has a dirty hack:
-Dmaven.resolver.transfer.logging=full(as before)|half(the new default)
As expected, one IT fails that asserts the "DownloadING" log line that this
Pr
Maybe we should just move the console listener to a logger usage with this
pattern $classname.event, this way configuring the loggers enables any
customization and we dont get fishy console outputs too depending the slf4j
binding.
Le dim. 19 févr. 2023 à 20:57, Benjamin Marwell a
écrit :
> Sadly
Sadly, --ntp also disables upload progress and ANY information associated
with this.
Maybe it would be beneficial to have an option for that.
On Sun, 19 Feb 2023, 18:26 Michael Osipov, wrote:
> Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > Not sure we can find an agreement on this to
Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
Not sure we can find an agreement on this topic, both opinions are very
valid and depends the persona/case so let's keep our default while it is
customizable easily it is fine IMHO.
Good point, I could imagine that one could introduce --transfe
Not sure we can find an agreement on this topic, both opinions are very
valid and depends the persona/case so let's keep our default while it is
customizable easily it is fine IMHO.
Le dim. 19 févr. 2023 à 17:06, Elliotte Rusty Harold a
écrit :
> On Sun, Feb 19, 2023 at 2:02 PM Michael Osipov
>
On Sun, Feb 19, 2023 at 2:02 PM Michael Osipov wrote:
> Use -B or --no-transfer-progress. Cutting in half does not really work
> unless you don't want to say that download has started and finished *or*
> you provide a custom status listener. Consider that download starts, but
> then fails. No way
, 09:13 Tamás Cservenák wrote:
> This is resolver, but the logging listener is provided by maven.
>
> I'd +1 for this, as message can be "Downloaded" or "Failed to
> download..." and imo line for starting of download is chatty, really not
> needed.
>
&
This is resolver, but the logging listener is provided by maven.
I'd +1 for this, as message can be "Downloaded" or "Failed to
download..." and imo line for starting of download is chatty, really not
needed.
T
On Sun, Feb 19, 2023, 14:59 Elliotte Rusty Harold
wrot
Am 2023-02-19 um 14:58 schrieb Elliotte Rusty Harold:
Typical log message in build:
Downloading from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/common
Typical log message in build:
Downloading from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
Downloaded from central:
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
(14 kB at 776 kB/s)
Which plugin does th
as
soon as maven leaks any 3rd party library we get troubles so even for
logging the rule of thumb should probably be to not leak anything else than
a controlled or JRE api which means for logging org.apache.maven.api.log.*
or JUL.
Once again for internals we can get debates but seems there had be
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()
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 wra
> 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
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
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 lo
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
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 migh
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
> 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 documen
c 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 purpose
> - In shared libraries used by Maven and maintained by
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
gins and extensions since
for the core codebase we don't care which solution we use but it just moves
the choice to the later stage and lead the same solution.
In terms of biggest issue I guess it is the ones people face, logging is a
common one, not sure others you have in mind but this one and classl
issue, slf4j is just ultra
> visible due to its past adoption.
>
> If it helps, we got the same topic at tomee (with log4j1 at that time) and
> the move to JUL was leading to the same kind of thread but after the change
> we got way less logging issues and related bugs and not much com
hatever its own quality when used outside
a pluggable system.
So yes, leaking *any* not maven owned API is an issue, slf4j is just ultra
visible due to its past adoption.
If it helps, we got the same topic at tomee (with log4j1 at that time) and
the move to JUL was leading to the same kind of threa
evelopers using framework"
begs the question:
what framework are we talking about? And how common is this story? What
percentage of Maven
plugins USE a "framework"?
my 5 cents.
T
On Fri, Nov 4, 2022 at 11:56 AM Slawomir Jaranowski
wrote:
> Hi,
>
> I want to start ( ag
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
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
Hi,
I want to start ( again :-) ) a discussion about logging in Maven plugins.
First I agree that plugin developers should use logging methods provided by
Plugin api.
But we can not expect plugin developers to write everything from scratch.
In many cases they may want to use an external library
michael-o opened a new pull request #80:
URL: https://github.com/apache/maven-doxia/pull/80
This closes #80
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe,
/pull/4
The sooner the hint is on the logging page, the better (if all agree,
of course).
Am Fr., 22. Jan. 2021 um 11:30 Uhr schrieb Robert Scholte
:
>
> I agree that we should advice that Maven Plugins should use the provided
> logging API.
> I can't find the ticket anymore, but
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 l
evelopers logging api in plugin will can be misunderstood, we don't
> have information that https://maven.apache.org/maven-logging.html is only
> for maven core.
>
> I think we should put information that plugins should only use
> org.apache.maven.plugin.logging.Log an
Hi,
For developers logging api in plugin will can be misunderstood, we don't
have information that https://maven.apache.org/maven-logging.html is only
for maven core.
I think we should put information that plugins should only use
org.apache.maven.plugin.logging.Log and why, maybe at page:
slachiewicz closed pull request #8:
URL: https://github.com/apache/maven-doxia/pull/8
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go t
abelsromero commented on pull request #5:
URL: https://github.com/apache/maven-doxia/pull/5#issuecomment-651344760
> I'm not in favor of removing doxia-logging: deprecating and modifying it
to use slf4j would be more compatible
> I know there are not so much Doxia extensions
sounds like 2
> > topics even if it could be a single one to unify the logging in the whole
> > maven project.
> >
>
> Can you elaborate on what you mean by "expose"? No SLF4J types in
> public APIs? No transitive dependencies on SLF4J?
>
No promoted SLF4J packa
On Mon, Jun 1, 2020 at 1:06 AM Romain Manni-Bucau wrote:
>
> So overall: +1 to clean up any internal from plexus but we should keep in
> mind we must not expose SLF4J in *plugins* - once again it sounds like 2
> topics even if it could be a single one to unify the logging in the w
1 - 100 of 528 matches
Mail list logo
