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 <rfscho...@apache.org> 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 <rmannibu...@gmail.com> 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 > > >
