Re: Loging api in JSR-330 component

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Loging api in JSR-330 component

Robert Scholte-8
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.
Think of Maven Extensions. I'd say they should be using the SLF4J API because their context is not bound to 1 plugin.

thanks,
Robert
On 18-1-2021 09:34:01, Romain Manni-Bucau <[hidden email]> wrote:
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 Jaranowski
a écrit :

> 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.
>
> --
> Sławomir Jaranowski
>
Reply | Threaded
Open this post in threaded view
|

Re: Loging api in JSR-330 component

Slawomir Jaranowski
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
    private Logger??? logger;
}

So the question is what logger we should use in the component?

Another case is that components can be Singleton and their instance will be
created once.


pt., 22 sty 2021 o 12:36 Romain Manni-Bucau <[hidden email]>
napisał(a):

> 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 code itself since we guarantee and own it.
> Should we promote the abstraction for extensions too?
>
> Le ven. 22 janv. 2021 à 11:41, Robert Scholte <[hidden email]> a
> écrit :
>
> > 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.
> > Think of Maven Extensions. I'd say they should be using the SLF4J API
> > because their context is not bound to 1 plugin.
> >
> > thanks,
> > Robert
> > On 18-1-2021 09:34:01, Romain Manni-Bucau <[hidden email]> wrote:
> > 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 Jaranowski
> > a écrit :
> >
> > > 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.
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>


--
Sławomir Jaranowski
Reply | Threaded
Open this post in threaded view
|

Re: Loging api in JSR-330 component

Benjamin Marwell-2
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, <[hidden email]>
wrote:

> Hi Benjamin,
>
> Guess it was unexpectedly deprecated, let's revert that on master.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le sam. 23 janv. 2021 à 17:58, Benjamin Marwell <[hidden email]> a
> écrit :
>
> > 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, <[hidden email]> wrote:
> >
> > > 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 <[hidden email]>
> > wrote:
> > > 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
> > > private Logger??? logger;
> > > }
> > >
> > > So the question is what logger we should use in the component?
> > >
> > > Another case is that components can be Singleton and their instance
> will
> > be
> > > created once.
> > >
> > >
> > > pt., 22 sty 2021 o 12:36 Romain Manni-Bucau
> > > napisał(a):
> > >
> > > > 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 code itself since we guarantee and own
> > it.
> > > > Should we promote the abstraction for extensions too?
> > > >
> > > > Le ven. 22 janv. 2021 à 11:41, Robert Scholte a
> > > > écrit :
> > > >
> > > > > 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.
> > > > > Think of Maven Extensions. I'd say they should be using the SLF4J
> API
> > > > > because their context is not bound to 1 plugin.
> > > > >
> > > > > thanks,
> > > > > Robert
> > > > > On 18-1-2021 09:34:01, Romain Manni-Bucau wrote:
> > > > > 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 Jaranowski
> > > > > a écrit :
> > > > >
> > > > > > 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.
> > > > > >
> > > > > > --
> > > > > > Sławomir Jaranowski
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Loging api in JSR-330 component

Matthieu BROUILLARD-3
In reply to this post by Slawomir Jaranowski
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 <[hidden email]>
wrote:

> 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 Matthieu Brouillard
> <[hidden email]> wrote:
> >
> > Issues MNG-7082 <https://issues.apache.org/jira/browse/MNG-7082>,
> MNG-7083
> > <https://issues.apache.org/jira/browse/MNG-7083>, MNG-7084
> > <https://issues.apache.org/jira/browse/MNG-7084> and MNG-7085
> > <https://issues.apache.org/jira/browse/MNG-7085> created for
> traceability.
> >
> > I'll push PRs for the first two.
> >
> > On Mon, Jan 25, 2021 at 11:57 AM Romain Manni-Bucau <
> [hidden email]>
> > wrote:
> >
> > > For me only 1 and 4 are "strictly required" but this plan works with
> the
> > > nice to have additions.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 25 janv. 2021 à 11:51, Matthieu Brouillard <
> [hidden email]
> > > >
> > > a écrit :
> > >
> > > > 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.maven.plugin.logging.Log'
> > > > * issue-3: enable injection of org.apache.maven.plugin.logging.Log
> > > >   + discuss further in the issue which implementation to inject
> > > where/when
> > > >   + document (where ?) usage for extensions & non mojo injectable
> classes
> > > > * issue-4: update 'https://maven.apache.org/maven-logging.html' (or
> > > > elsewhere ?) with latest recommandations
> > > >   + use #getLog() for mojos
> > > >   + use injection for other use cases
> > > >
> > > > If it is ok then I'll create those issues and start working on the 2
> > > first.
> > > > Once created people will be able to provide additional context or
> > > > information to each ticket.
> > > >
> > > > Matthieu
> > > >
> > > > On Mon, Jan 25, 2021 at 8:07 AM Guillaume Nodet <[hidden email]>
> > > wrote:
> > > >
> > > > > +1 for giving the logging API a bit of love with Supplier<String>
> > > and/or
> > > > > formatter-like api.
> > > > >
> > > > > Guillaume Nodet
> > > > >
> > > > > Le lun. 25 janv. 2021 à 07:41, Mark Struberg
> <[hidden email]
> > > >
> > > > a
> > > > > écrit :
> > > > >
> > > > > >  +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 not necessary. They just
> > > > > > unnecessarily create classpatch clashes some times (been there
> done
> > > > > that).
> > > > > >
> > > > > > LieGrue,strub
> > > > > >
> > > > > >     On Saturday, 23 January 2021, 18:06:34 CET, Romain
> Manni-Bucau <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > >  Hi Benjamin,
> > > > > >
> > > > > > Guess it was unexpectedly deprecated, let's revert that on
> master.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Le sam. 23 janv. 2021 à 17:58, Benjamin Marwell <
> [hidden email]
> > > >
> > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > 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, <
> [hidden email]>
> > > > > wrote:
> > > > > > >
> > > > > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > > wrote:
> > > > > > > > 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
> > > > > > > > private Logger??? logger;
> > > > > > > > }
> > > > > > > >
> > > > > > > > So the question is what logger we should use in the
> component?
> > > > > > > >
> > > > > > > > Another case is that components can be Singleton and their
> > > instance
> > > > > > will
> > > > > > > be
> > > > > > > > created once.
> > > > > > > >
> > > > > > > >
> > > > > > > > pt., 22 sty 2021 o 12:36 Romain Manni-Bucau
> > > > > > > > napisał(a):
> > > > > > > >
> > > > > > > > > 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 code itself since we
> guarantee
> > > and
> > > > > own
> > > > > > > it.
> > > > > > > > > Should we promote the abstraction for extensions too?
> > > > > > > > >
> > > > > > > > > Le ven. 22 janv. 2021 à 11:41, Robert Scholte a
> > > > > > > > > écrit :
> > > > > > > > >
> > > > > > > > > > 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.
> > > > > > > > > > Think of Maven Extensions. I'd say they should be using
> the
> > > > SLF4J
> > > > > > API
> > > > > > > > > > because their context is not bound to 1 plugin.
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > > Robert
> > > > > > > > > > On 18-1-2021 09:34:01, Romain Manni-Bucau wrote:
> > > > > > > > > > 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 Jaranowski
> > > > > > > > > > a écrit :
> > > > > > > > > >
> > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Sławomir Jaranowski
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Loging api in JSR-330 component

Sylwester Lachiewicz
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 affect users users but also our
core plugins. We should discuss about time impact - like now few plugins
still depends on API 2.0 (anyone willing to help with migration?) And only
since last year we started migration to Maven api 3.1+ having migrated
maybe 10 out of 100s our repos, still based on Java 7:-)) so migration path
is also important, guidelines how to migrate, how to mix maven plugin
logging with shared Maven components and with external libraries (that may
use SLF4J, java logging or log4j). How to do troubleshooting plugin
logging.
And last but not least - what problem we are solving, what features and
benefits we want to get after?


Sylwester

pon., 25 sty 2021, 19:14 użytkownik Elliotte Rusty Harold <
[hidden email]> napisał:

> 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 a lot of technical debt, and a large part of that is both a
> symptom and a cause of outdated, incomplete, and inconsistent
> documentation. Long time committers routinely suggest contradictory
> approaches as the way Maven does things. The only way I know to avoid
> this is to have normative, maintained documentation of agreed
> development practices that is in the source repo and published on the
> web site. This helps flush out and resolve areas where different
> committers believe different things to be true. When a conflict
> arises, it can be settled by reference to the docs. If the docs don't
> speak to the issue at hand, then the point can be discussed and the
> resolution added to the docs.
>
> Issues and mailing list threads from years ago (and even if it's
> current today, it will be years ago soon) are not sufficient. Relying
> on this has helped us into the morass we're in now in multiple areas,
> not just logging.
>
> On Mon, Jan 25, 2021 at 5:38 PM Matthieu Brouillard
> <[hidden email]> wrote:
> >
> > 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 <
> [hidden email]>
> > wrote:
> >
> > > 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 Matthieu Brouillard
> > > <[hidden email]> wrote:
> > > >
> > > > Issues MNG-7082 <https://issues.apache.org/jira/browse/MNG-7082>,
> > > MNG-7083
> > > > <https://issues.apache.org/jira/browse/MNG-7083>, MNG-7084
> > > > <https://issues.apache.org/jira/browse/MNG-7084> and MNG-7085
> > > > <https://issues.apache.org/jira/browse/MNG-7085> created for
> > > traceability.
> > > >
> > > > I'll push PRs for the first two.
> > > >
> > > > On Mon, Jan 25, 2021 at 11:57 AM Romain Manni-Bucau <
> > > [hidden email]>
> > > > wrote:
> > > >
> > > > > For me only 1 and 4 are "strictly required" but this plan works
> with
> > > the
> > > > > nice to have additions.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > > >
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le lun. 25 janv. 2021 à 11:51, Matthieu Brouillard <
> > > [hidden email]
> > > > > >
> > > > > a écrit :
> > > > >
> > > > > > 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.maven.plugin.logging.Log'
> > > > > > * issue-3: enable injection of
> org.apache.maven.plugin.logging.Log
> > > > > >   + discuss further in the issue which implementation to inject
> > > > > where/when
> > > > > >   + document (where ?) usage for extensions & non mojo injectable
> > > classes
> > > > > > * issue-4: update 'https://maven.apache.org/maven-logging.html'
> (or
> > > > > > elsewhere ?) with latest recommandations
> > > > > >   + use #getLog() for mojos
> > > > > >   + use injection for other use cases
> > > > > >
> > > > > > If it is ok then I'll create those issues and start working on
> the 2
> > > > > first.
> > > > > > Once created people will be able to provide additional context or
> > > > > > information to each ticket.
> > > > > >
> > > > > > Matthieu
> > > > > >
> > > > > > On Mon, Jan 25, 2021 at 8:07 AM Guillaume Nodet <
> [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > > +1 for giving the logging API a bit of love with
> Supplier<String>
> > > > > and/or
> > > > > > > formatter-like api.
> > > > > > >
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > > Le lun. 25 janv. 2021 à 07:41, Mark Struberg
> > > <[hidden email]
> > > > > >
> > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > >  +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 not necessary. They
> just
> > > > > > > > unnecessarily create classpatch clashes some times (been
> there
> > > done
> > > > > > > that).
> > > > > > > >
> > > > > > > > LieGrue,strub
> > > > > > > >
> > > > > > > >     On Saturday, 23 January 2021, 18:06:34 CET, Romain
> > > Manni-Bucau <
> > > > > > > > [hidden email]> wrote:
> > > > > > > >
> > > > > > > >  Hi Benjamin,
> > > > > > > >
> > > > > > > > Guess it was unexpectedly deprecated, let's revert that on
> > > master.
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Le sam. 23 janv. 2021 à 17:58, Benjamin Marwell <
> > > [hidden email]
> > > > > >
> > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > > 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, <
> > > [hidden email]>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > [hidden email]
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > 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
> > > > > > > > > > private Logger??? logger;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > So the question is what logger we should use in the
> > > component?
> > > > > > > > > >
> > > > > > > > > > Another case is that components can be Singleton and
> their
> > > > > instance
> > > > > > > > will
> > > > > > > > > be
> > > > > > > > > > created once.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > pt., 22 sty 2021 o 12:36 Romain Manni-Bucau
> > > > > > > > > > napisał(a):
> > > > > > > > > >
> > > > > > > > > > > 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 code itself since we
> > > guarantee
> > > > > and
> > > > > > > own
> > > > > > > > > it.
> > > > > > > > > > > Should we promote the abstraction for extensions too?
> > > > > > > > > > >
> > > > > > > > > > > Le ven. 22 janv. 2021 à 11:41, Robert Scholte a
> > > > > > > > > > > écrit :
> > > > > > > > > > >
> > > > > > > > > > > > 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.
> > > > > > > > > > > > Think of Maven Extensions. I'd say they should be
> using
> > > the
> > > > > > SLF4J
> > > > > > > > API
> > > > > > > > > > > > because their context is not bound to 1 plugin.
> > > > > > > > > > > >
> > > > > > > > > > > > thanks,
> > > > > > > > > > > > Robert
> > > > > > > > > > > > On 18-1-2021 09:34:01, Romain Manni-Bucau wrote:
> > > > > > > > > > > > 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 Jaranowski
> > > > > > > > > > > > a écrit :
> > > > > > > > > > > >
> > > > > > > > > > > > > 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.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Loging api in JSR-330 component

Benjamin Marwell-2
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. Jan. 2021 um 12:50 Uhr schrieb Sylwester Lachiewicz
<[hidden email]>:

>
> 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 affect users users but also our
> core plugins. We should discuss about time impact - like now few plugins
> still depends on API 2.0 (anyone willing to help with migration?) And only
> since last year we started migration to Maven api 3.1+ having migrated
> maybe 10 out of 100s our repos, still based on Java 7:-)) so migration path
> is also important, guidelines how to migrate, how to mix maven plugin
> logging with shared Maven components and with external libraries (that may
> use SLF4J, java logging or log4j). How to do troubleshooting plugin
> logging.
> And last but not least - what problem we are solving, what features and
> benefits we want to get after?
>
>
> Sylwester
>
> pon., 25 sty 2021, 19:14 użytkownik Elliotte Rusty Harold <
> [hidden email]> napisał:
>
> > 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 a lot of technical debt, and a large part of that is both a
> > symptom and a cause of outdated, incomplete, and inconsistent
> > documentation. Long time committers routinely suggest contradictory
> > approaches as the way Maven does things. The only way I know to avoid
> > this is to have normative, maintained documentation of agreed
> > development practices that is in the source repo and published on the
> > web site. This helps flush out and resolve areas where different
> > committers believe different things to be true. When a conflict
> > arises, it can be settled by reference to the docs. If the docs don't
> > speak to the issue at hand, then the point can be discussed and the
> > resolution added to the docs.
> >
> > Issues and mailing list threads from years ago (and even if it's
> > current today, it will be years ago soon) are not sufficient. Relying
> > on this has helped us into the morass we're in now in multiple areas,
> > not just logging.
> >
> > On Mon, Jan 25, 2021 at 5:38 PM Matthieu Brouillard
> > <[hidden email]> wrote:
> > >
> > > 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 <
> > [hidden email]>
> > > wrote:
> > >
> > > > 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 Matthieu Brouillard
> > > > <[hidden email]> wrote:
> > > > >
> > > > > Issues MNG-7082 <https://issues.apache.org/jira/browse/MNG-7082>,
> > > > MNG-7083
> > > > > <https://issues.apache.org/jira/browse/MNG-7083>, MNG-7084
> > > > > <https://issues.apache.org/jira/browse/MNG-7084> and MNG-7085
> > > > > <https://issues.apache.org/jira/browse/MNG-7085> created for
> > > > traceability.
> > > > >
> > > > > I'll push PRs for the first two.
> > > > >
> > > > > On Mon, Jan 25, 2021 at 11:57 AM Romain Manni-Bucau <
> > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > For me only 1 and 4 are "strictly required" but this plan works
> > with
> > > > the
> > > > > > nice to have additions.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > > >
> > > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Le lun. 25 janv. 2021 à 11:51, Matthieu Brouillard <
> > > > [hidden email]
> > > > > > >
> > > > > > a écrit :
> > > > > >
> > > > > > > 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.maven.plugin.logging.Log'
> > > > > > > * issue-3: enable injection of
> > org.apache.maven.plugin.logging.Log
> > > > > > >   + discuss further in the issue which implementation to inject
> > > > > > where/when
> > > > > > >   + document (where ?) usage for extensions & non mojo injectable
> > > > classes
> > > > > > > * issue-4: update 'https://maven.apache.org/maven-logging.html'
> > (or
> > > > > > > elsewhere ?) with latest recommandations
> > > > > > >   + use #getLog() for mojos
> > > > > > >   + use injection for other use cases
> > > > > > >
> > > > > > > If it is ok then I'll create those issues and start working on
> > the 2
> > > > > > first.
> > > > > > > Once created people will be able to provide additional context or
> > > > > > > information to each ticket.
> > > > > > >
> > > > > > > Matthieu
> > > > > > >
> > > > > > > On Mon, Jan 25, 2021 at 8:07 AM Guillaume Nodet <
> > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > > +1 for giving the logging API a bit of love with
> > Supplier<String>
> > > > > > and/or
> > > > > > > > formatter-like api.
> > > > > > > >
> > > > > > > > Guillaume Nodet
> > > > > > > >
> > > > > > > > Le lun. 25 janv. 2021 à 07:41, Mark Struberg
> > > > <[hidden email]
> > > > > > >
> > > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > >  +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 not necessary. They
> > just
> > > > > > > > > unnecessarily create classpatch clashes some times (been
> > there
> > > > done
> > > > > > > > that).
> > > > > > > > >
> > > > > > > > > LieGrue,strub
> > > > > > > > >
> > > > > > > > >     On Saturday, 23 January 2021, 18:06:34 CET, Romain
> > > > Manni-Bucau <
> > > > > > > > > [hidden email]> wrote:
> > > > > > > > >
> > > > > > > > >  Hi Benjamin,
> > > > > > > > >
> > > > > > > > > Guess it was unexpectedly deprecated, let's revert that on
> > > > master.
> > > > > > > > >
> > > > > > > > > Romain Manni-Bucau
> > > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Le sam. 23 janv. 2021 à 17:58, Benjamin Marwell <
> > > > [hidden email]
> > > > > > >
> > > > > > > a
> > > > > > > > > écrit :
> > > > > > > > >
> > > > > > > > > > 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, <
> > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > 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
> > > > > > > > > > > private Logger??? logger;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > So the question is what logger we should use in the
> > > > component?
> > > > > > > > > > >
> > > > > > > > > > > Another case is that components can be Singleton and
> > their
> > > > > > instance
> > > > > > > > > will
> > > > > > > > > > be
> > > > > > > > > > > created once.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > pt., 22 sty 2021 o 12:36 Romain Manni-Bucau
> > > > > > > > > > > napisał(a):
> > > > > > > > > > >
> > > > > > > > > > > > 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 code itself since we
> > > > guarantee
> > > > > > and
> > > > > > > > own
> > > > > > > > > > it.
> > > > > > > > > > > > Should we promote the abstraction for extensions too?
> > > > > > > > > > > >
> > > > > > > > > > > > Le ven. 22 janv. 2021 à 11:41, Robert Scholte a
> > > > > > > > > > > > écrit :
> > > > > > > > > > > >
> > > > > > > > > > > > > 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.
> > > > > > > > > > > > > Think of Maven Extensions. I'd say they should be
> > using
> > > > the
> > > > > > > SLF4J
> > > > > > > > > API
> > > > > > > > > > > > > because their context is not bound to 1 plugin.
> > > > > > > > > > > > >
> > > > > > > > > > > > > thanks,
> > > > > > > > > > > > > Robert
> > > > > > > > > > > > > On 18-1-2021 09:34:01, Romain Manni-Bucau wrote:
> > > > > > > > > > > > > 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 Jaranowski
> > > > > > > > > > > > > a écrit :
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Sławomir Jaranowski
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]