Re: Loging api in JSR-330 component

1. and 4. are just reverting previous behaviour which was changed just recently. I see no need to discuss the impact. For 2. and 3. I agree, discussion is needed as it is new (lazy evaluation and injection). But tbh, the real need is just 3 for me. lazy eval is just another new API. Am Di., 26.

Re: Loging api in JSR-330 component

I fully agree here with Elliotte - before going to implement changes to loging we should have vision doc (maybe something smilar to other projects like Kafka KIP?). There are many aspects of this type of changes that should be described and analyzed. Having in mind that changes to that API wi affec

Re: Loging api in JSR-330 component

Elliotte, MNG-7085 actually *IS* about updating the pages you mentioned. If it is missing something (eg doc updates), we should add it to the issue’s description. Maybe this one needs some measurable fulfillment criteria. Am Mo., 25. Jan. 2021 um 19:14 Uhr schrieb Elliotte Rusty Harold : > > No,

Re: Loging api in JSR-330 component

No, an issue is too easily forgotten. We should have something on the main web site. It needs to be consistent with or replace: https://maven.apache.org/maven-jsr330.html https://maven.apache.org/maven-logging.html In addition the API docs of the relevant libraries need to be updated. Maven has

Re: Loging api in JSR-330 component

is MNG-7085 [1] suited for that ? Or do you propose that another (or existing) design document is written first covering all the logging use-cases ? [1]: https://issues.apache.org/jira/browse/MNG-7085 On Mon, Jan 25, 2021 at 6:12 PM Elliotte Rusty Harold wrote: > It would really help to have a

Re: Loging api in JSR-330 component

It would really help to have a complete, up-to-date design doc for Maven logging first, as well as clearing lout obsolete docs. Absent that there's a lot of crosstalk and conflicting updates across projects. It's not obvious everyone understands the same consensus. On Mon, Jan 25, 2021 at 3:45 PM

Re: Loging api in JSR-330 component

Issues MNG-7082 , MNG-7083 , MNG-7084 and MNG-7085 created for traceability. I'll push PRs for the first

Re: Loging api in JSR-330 component

For me only 1 and 4 are "strictly required" but this plan works with the nice to have additions. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | L

Re: Loging api in JSR-330 component

In order to go further on this topic, I'd like to create issues for each discussed topic in this thread and probably start working on some: * issue-1: remove depreciation on 'org.apache.maven.plugin.logging.Log' * issue-2: introduce lazy evaluation/message production for each level in 'org.apache.

Re: Loging api in JSR-330 component

+1 for giving the logging API a bit of love with Supplier and/or formatter-like api. Guillaume Nodet Le lun. 25 janv. 2021 à 07:41, Mark Struberg a écrit : > +1Technically from a pure ClassLoader point our very own makes more > sense.We can probably think about Lambda to resolve the String > l

Re: Loging api in JSR-330 component

+1Technically from a pure ClassLoader point our very own makes more sense.We can probably think about Lambda to resolve the String lazily.Insofar the SLF4J api is outdated as well. And of course internally we might still route to slf4j. But we should not expose those classes to the plugins if n

Re: Loging api in JSR-330 component

    @Inject     private Logger??? logger; That would imo depend on the package of the Logger in the import. There could be producers for both our internal maven logging api and SLF4J. LieGrue,strub On Friday, 22 January 2021, 19:19:47 CET, Slawomir Jaranowski wrote: It is not only a

Re: Loging api in JSR-330 component

Probably because of the same misunderstanding why this thread came up in the first place. https://issues.apache.org/jira/browse/MNG-6931 and https://github.com/apache/maven/pull/385 +1 for reverting and adding some documentation. On Sat, 23 Jan 2021, 18:06 Romain Manni-Bucau, wrote: > Hi Be

Re: Loging api in JSR-330 component

Hi Benjamin, Guess it was unexpectedly deprecated, let's revert that on master. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

Re: Loging api in JSR-330 component

Robert, that's deprecated! What to use instead? Or was it deprecated in error? https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/java/org/apache/maven/plugin/logging/Log.java On Sat, 23 Jan 2021, 12:10 Robert Scholte, wrote: > See > https://maven.apache.org/ref/3.6.3/ma

Re: Loging api in JSR-330 component

See https://maven.apache.org/ref/3.6.3/maven-plugin-api/apidocs/org/apache/maven/plugin/AbstractMojo.html You can get the logger by calling getLog(), so don't inject the logger here. Robert On 22-1-2021 19:19:47, Slawomir Jaranowski wrote: It is not only an extension case. For example I can wr

Re: Loging api in JSR-330 component

Mojo scope is clearly the abstraction, no doubt here. I think extension too by design as explained but guess we never discuss it. Personally I'd rather generalize the abstraction since we reimpl slf4j - even if fork is trivial - anyway so maybe we should finally shout something which never matched

Re: Loging api in JSR-330 component

It is not only an extension case. For example I can write Mojo like: @Mojo(name = "example") public class ExampleMojo extends AbstractMojo { @Inject private MyService myService; @Override public void execute() { } } and @Named public class MyService { @Inject priv

Re: Loging api in JSR-330 component

Do it means if we represent our classloading structure, all loaders on top of mojo use slf4j and others our maven abstraction. Sounds ok to me except for extensions which are not in maven land so subject to slf4j api breaking changes and undefined/ambiguous context - which is never true for maven c

Re: Loging api in JSR-330 component

I'm not so sure about this, it probably depends on the context. I think we should assume that JSR330 component are not aware of their context.  They should not require a Maven context, hence in such case it makes sense to use SLF4J API, while the application selects the logger implementation. Thi

Re: Loging api in JSR-330 component

Generally you want to propagate the mojo logger to have consistent logs but worse case we should promote mojo logging api as injectable at injection points if needed, avoids all the mess you can get in mojo with loggers to respect that rule of dumb IMHO. Le dim. 17 janv. 2021 à 22:48, Slawomir Jar

Loging api in JSR-330 component

Hi, We can use the JSR-330 component for developing maven plugins - https://maven.apache.org/maven-jsr330.html There is not clear how to access logging api from JSR-330 component. As I found out last time, maven plugins should not directly use slf4j-api, so what is recommended in this case. --