You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christopher <ct...@apache.org> on 2016/08/12 21:48:26 UTC
slf4j runtime dependency for plugin
Hi,
I use a plugin which has a runtime dependency on an slf4j implementation,
but the plugin itself is built without declaring one in its pom. (
https://github.com/koraktor/mavanagaiata/issues/43)
In some versions of Maven, I get a warning about slf4j not finding an
implementation. In other versions, it is silent.
Was an slf4j implementation provided in newer versions to the execution of
plugins?
Will there be a multiple-binding conflict if the plugin itself provides one
of its own to get rid of the warning on certain versions of maven which
result in that warning (I didn't see one when I tried)?
If there is a risk of a conflict, which implementation would be preferred
in order to converge on one provided by Maven?
Is there another solution the plugin should seek?
In general, what dependencies are plugins expected to provide, and what
dependencies are expected to be provided by Maven, and how are conflicts
resolved in the architecture?
Feel free to comment on the GitHub issue directly, or here. I'll be
watching both.
Thanks.
Re: slf4j runtime dependency for plugin
Posted by Christian Schulte <cs...@schulte.it>.
Am 08/15/16 um 22:21 schrieb Fred Cooke:
> Something doesn't have to be in Java to be universal (as SLF4J really is),
> and conversely, something being in Java doesn't make the world instantly
> catch up (eg YodaTime vs J8+).
Or java.util.logging. Almost not used anywhere.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: slf4j runtime dependency for plugin
Posted by Fred Cooke <fr...@gmail.com>.
Something doesn't have to be in Java to be universal (as SLF4J really is),
and conversely, something being in Java doesn't make the world instantly
catch up (eg YodaTime vs J8+).
Adding the nop logger as a dep seems like the wrong thing to do and will
(IIRC) cause a warning/error at runtime if there's another one present.
Leaving it out (IIRC) falls back to that anyway with a warning given. IE, I
don't think adding that does any good whatsoever.
IIRCs because it's been a long time since I had this misconfigured :-)
On Tue, Aug 16, 2016 at 4:47 AM, Christopher <ct...@apache.org> wrote:
> On Mon, Aug 15, 2016 at 2:37 AM Michael Osipov <mi...@apache.org>
> wrote:
>
> > Am 2016-08-14 um 23:21 schrieb Christopher:
> > > On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <mi...@apache.org>
> > wrote:
> > >
> > >> Am 2016-08-12 um 23:48 schrieb Christopher:
> > >>> Hi,
> > >>>
> > >>> I use a plugin which has a runtime dependency on an slf4j
> > implementation,
> > >>> but the plugin itself is built without declaring one in its pom. (
> > >>> https://github.com/koraktor/mavanagaiata/issues/43)
> > >>>
> > >>> In some versions of Maven, I get a warning about slf4j not finding an
> > >>> implementation. In other versions, it is silent.
> > >>>
> > >>> Was an slf4j implementation provided in newer versions to the
> execution
> > >> of
> > >>> plugins?
> > >>>
> > >>> Will there be a multiple-binding conflict if the plugin itself
> provides
> > >> one
> > >>> of its own to get rid of the warning on certain versions of maven
> which
> > >>> result in that warning (I didn't see one when I tried)?
> > >>>
> > >>> If there is a risk of a conflict, which implementation would be
> > preferred
> > >>> in order to converge on one provided by Maven?
> > >>>
> > >>> Is there another solution the plugin should seek?
> > >>>
> > >>> In general, what dependencies are plugins expected to provide, and
> what
> > >>> dependencies are expected to be provided by Maven, and how are
> > conflicts
> > >>> resolved in the architecture?
> > >>>
> > >>> Feel free to comment on the GitHub issue directly, or here. I'll be
> > >>> watching both.
> > >>
> > >> I will cite what I have written on Stack Overflow
> > >> (http://stackoverflow.com/a/7107934/696632) five years ago and it
> still
> > >> holds true:
> > >>
> > >> You *never* provide a log implementation. The client application has
> to
> > >> do so. Otherwhise this would be a violation of separation of concerns.
> > >> Don't do any assumptions about an unknown client.
> > >>
> > >>
> > > I agree with that sentiment...generally. But this is a maven plugin, so
> > I'm
> > > trying to figure out what Maven is going to provide it when it
> executes.
> > If
> > > it's not going to provide an implementation, then the plugin has to. If
> > you
> > > have answers to the specific questions I asked above, I think it might
> > help.
> >
> > It should not matter to you what Maven provides. It will always provide
> > some backend. Otherwise Maven won't be able to log itself. Even if
> > Maven would not provide anything. It is not your task to force some
> > implementation. It is a several failure of the client to do so.
> >
> > Michael
> >
>
> That would make more sense to me if there were a universally agreed upon
> logging API, and all clients were guaranteed to provide *some* backend for
> that standard logging API. Unfortunately, no logging API seems to be
> universal, and the one provided in Java itself is awful. I'm not even sure
> what Maven uses underneath, and it may not use SLF4J at all (which means it
> has no reason to provide an implementation).
>
> This is actually a pretty unfortunate circumstance in the first place...
> Maven plugins should only be logging to the provided Maven logger itself,
> and the plugin shouldn't care what backend Maven is using for that logger.
> This
> particular plugin is doing the right thing... using the Maven logger and
> relying on Maven for the backend. Unfortunately, it seems the
> org.eclipse.jgit dependency does its own logging, and that's outside this
> plugin's control.
>
> Until there is a universal logging framework, these heuristics about what
> the "right" thing to do are not going to be perfect. Ideals like "rely on
> the client to provide the implementation" aren't going to fully match
> reality. Personally, I'd like to see an slf4j-like API make its way into
> Java itself. Then, perhaps these kinds of issues wouldn't come up as often.
>
Re: slf4j runtime dependency for plugin
Posted by Christopher <ct...@apache.org>.
On Mon, Aug 15, 2016 at 2:37 AM Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-14 um 23:21 schrieb Christopher:
> > On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <mi...@apache.org>
> wrote:
> >
> >> Am 2016-08-12 um 23:48 schrieb Christopher:
> >>> Hi,
> >>>
> >>> I use a plugin which has a runtime dependency on an slf4j
> implementation,
> >>> but the plugin itself is built without declaring one in its pom. (
> >>> https://github.com/koraktor/mavanagaiata/issues/43)
> >>>
> >>> In some versions of Maven, I get a warning about slf4j not finding an
> >>> implementation. In other versions, it is silent.
> >>>
> >>> Was an slf4j implementation provided in newer versions to the execution
> >> of
> >>> plugins?
> >>>
> >>> Will there be a multiple-binding conflict if the plugin itself provides
> >> one
> >>> of its own to get rid of the warning on certain versions of maven which
> >>> result in that warning (I didn't see one when I tried)?
> >>>
> >>> If there is a risk of a conflict, which implementation would be
> preferred
> >>> in order to converge on one provided by Maven?
> >>>
> >>> Is there another solution the plugin should seek?
> >>>
> >>> In general, what dependencies are plugins expected to provide, and what
> >>> dependencies are expected to be provided by Maven, and how are
> conflicts
> >>> resolved in the architecture?
> >>>
> >>> Feel free to comment on the GitHub issue directly, or here. I'll be
> >>> watching both.
> >>
> >> I will cite what I have written on Stack Overflow
> >> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> >> holds true:
> >>
> >> You *never* provide a log implementation. The client application has to
> >> do so. Otherwhise this would be a violation of separation of concerns.
> >> Don't do any assumptions about an unknown client.
> >>
> >>
> > I agree with that sentiment...generally. But this is a maven plugin, so
> I'm
> > trying to figure out what Maven is going to provide it when it executes.
> If
> > it's not going to provide an implementation, then the plugin has to. If
> you
> > have answers to the specific questions I asked above, I think it might
> help.
>
> It should not matter to you what Maven provides. It will always provide
> some backend. Otherwise Maven won't be able to log itself. Even if
> Maven would not provide anything. It is not your task to force some
> implementation. It is a several failure of the client to do so.
>
> Michael
>
That would make more sense to me if there were a universally agreed upon
logging API, and all clients were guaranteed to provide *some* backend for
that standard logging API. Unfortunately, no logging API seems to be
universal, and the one provided in Java itself is awful. I'm not even sure
what Maven uses underneath, and it may not use SLF4J at all (which means it
has no reason to provide an implementation).
This is actually a pretty unfortunate circumstance in the first place...
Maven plugins should only be logging to the provided Maven logger itself,
and the plugin shouldn't care what backend Maven is using for that logger. This
particular plugin is doing the right thing... using the Maven logger and
relying on Maven for the backend. Unfortunately, it seems the
org.eclipse.jgit dependency does its own logging, and that's outside this
plugin's control.
Until there is a universal logging framework, these heuristics about what
the "right" thing to do are not going to be perfect. Ideals like "rely on
the client to provide the implementation" aren't going to fully match
reality. Personally, I'd like to see an slf4j-like API make its way into
Java itself. Then, perhaps these kinds of issues wouldn't come up as often.
RE: slf4j runtime dependency for plugin
Posted by Martin Gainty <mg...@hotmail.com>.
Fred:he is missing slf4j-nop as a runtime dependency specifically:
<dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-nop</artifactId> <version>1.7.2</version> <scope>runtime</scope> </dependency>
Martin--
______________________________________________
> From: fred.cooke@gmail.com
> Date: Mon, 15 Aug 2016 22:13:45 +1200
> Subject: Re: slf4j runtime dependency for plugin
> To: dev@maven.apache.org
>
> Clearly it's going to matter to him if Maven fails to provide and it
> doesn't work. Some sort of dependency isolation not right somewhere?
> Something seems to be going on. You're right, but he's seeing behaviour
> that indicates something is amiss.
>
> On Mon, Aug 15, 2016 at 6:37 PM, Michael Osipov <mi...@apache.org> wrote:
>
> > Am 2016-08-14 um 23:21 schrieb Christopher:
> >
> >> On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <mi...@apache.org>
> >> wrote:
> >>
> >> Am 2016-08-12 um 23:48 schrieb Christopher:
> >>>
> >>>> Hi,
> >>>>
> >>>> I use a plugin which has a runtime dependency on an slf4j
> >>>> implementation,
> >>>> but the plugin itself is built without declaring one in its pom. (
> >>>> https://github.com/koraktor/mavanagaiata/issues/43)
> >>>>
> >>>> In some versions of Maven, I get a warning about slf4j not finding an
> >>>> implementation. In other versions, it is silent.
> >>>>
> >>>> Was an slf4j implementation provided in newer versions to the execution
> >>>>
> >>> of
> >>>
> >>>> plugins?
> >>>>
> >>>> Will there be a multiple-binding conflict if the plugin itself provides
> >>>>
> >>> one
> >>>
> >>>> of its own to get rid of the warning on certain versions of maven which
> >>>> result in that warning (I didn't see one when I tried)?
> >>>>
> >>>> If there is a risk of a conflict, which implementation would be
> >>>> preferred
> >>>> in order to converge on one provided by Maven?
> >>>>
> >>>> Is there another solution the plugin should seek?
> >>>>
> >>>> In general, what dependencies are plugins expected to provide, and what
> >>>> dependencies are expected to be provided by Maven, and how are conflicts
> >>>> resolved in the architecture?
> >>>>
> >>>> Feel free to comment on the GitHub issue directly, or here. I'll be
> >>>> watching both.
> >>>>
> >>>
> >>> I will cite what I have written on Stack Overflow
> >>> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> >>> holds true:
> >>>
> >>> You *never* provide a log implementation. The client application has to
> >>> do so. Otherwhise this would be a violation of separation of concerns.
> >>> Don't do any assumptions about an unknown client.
> >>>
> >>>
> >>> I agree with that sentiment...generally. But this is a maven plugin, so
> >> I'm
> >> trying to figure out what Maven is going to provide it when it executes.
> >> If
> >> it's not going to provide an implementation, then the plugin has to. If
> >> you
> >> have answers to the specific questions I asked above, I think it might
> >> help.
> >>
> >
> > It should not matter to you what Maven provides. It will always provide
> > some backend. Otherwise Maven won't be able to log itself. Even if Maven
> > would not provide anything. It is not your task to force some
> > implementation. It is a several failure of the client to do so.
> >
> > Michael
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
Re: slf4j runtime dependency for plugin
Posted by Fred Cooke <fr...@gmail.com>.
Clearly it's going to matter to him if Maven fails to provide and it
doesn't work. Some sort of dependency isolation not right somewhere?
Something seems to be going on. You're right, but he's seeing behaviour
that indicates something is amiss.
On Mon, Aug 15, 2016 at 6:37 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-14 um 23:21 schrieb Christopher:
>
>> On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <mi...@apache.org>
>> wrote:
>>
>> Am 2016-08-12 um 23:48 schrieb Christopher:
>>>
>>>> Hi,
>>>>
>>>> I use a plugin which has a runtime dependency on an slf4j
>>>> implementation,
>>>> but the plugin itself is built without declaring one in its pom. (
>>>> https://github.com/koraktor/mavanagaiata/issues/43)
>>>>
>>>> In some versions of Maven, I get a warning about slf4j not finding an
>>>> implementation. In other versions, it is silent.
>>>>
>>>> Was an slf4j implementation provided in newer versions to the execution
>>>>
>>> of
>>>
>>>> plugins?
>>>>
>>>> Will there be a multiple-binding conflict if the plugin itself provides
>>>>
>>> one
>>>
>>>> of its own to get rid of the warning on certain versions of maven which
>>>> result in that warning (I didn't see one when I tried)?
>>>>
>>>> If there is a risk of a conflict, which implementation would be
>>>> preferred
>>>> in order to converge on one provided by Maven?
>>>>
>>>> Is there another solution the plugin should seek?
>>>>
>>>> In general, what dependencies are plugins expected to provide, and what
>>>> dependencies are expected to be provided by Maven, and how are conflicts
>>>> resolved in the architecture?
>>>>
>>>> Feel free to comment on the GitHub issue directly, or here. I'll be
>>>> watching both.
>>>>
>>>
>>> I will cite what I have written on Stack Overflow
>>> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
>>> holds true:
>>>
>>> You *never* provide a log implementation. The client application has to
>>> do so. Otherwhise this would be a violation of separation of concerns.
>>> Don't do any assumptions about an unknown client.
>>>
>>>
>>> I agree with that sentiment...generally. But this is a maven plugin, so
>> I'm
>> trying to figure out what Maven is going to provide it when it executes.
>> If
>> it's not going to provide an implementation, then the plugin has to. If
>> you
>> have answers to the specific questions I asked above, I think it might
>> help.
>>
>
> It should not matter to you what Maven provides. It will always provide
> some backend. Otherwise Maven won't be able to log itself. Even if Maven
> would not provide anything. It is not your task to force some
> implementation. It is a several failure of the client to do so.
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: slf4j runtime dependency for plugin
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-14 um 23:21 schrieb Christopher:
> On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2016-08-12 um 23:48 schrieb Christopher:
>>> Hi,
>>>
>>> I use a plugin which has a runtime dependency on an slf4j implementation,
>>> but the plugin itself is built without declaring one in its pom. (
>>> https://github.com/koraktor/mavanagaiata/issues/43)
>>>
>>> In some versions of Maven, I get a warning about slf4j not finding an
>>> implementation. In other versions, it is silent.
>>>
>>> Was an slf4j implementation provided in newer versions to the execution
>> of
>>> plugins?
>>>
>>> Will there be a multiple-binding conflict if the plugin itself provides
>> one
>>> of its own to get rid of the warning on certain versions of maven which
>>> result in that warning (I didn't see one when I tried)?
>>>
>>> If there is a risk of a conflict, which implementation would be preferred
>>> in order to converge on one provided by Maven?
>>>
>>> Is there another solution the plugin should seek?
>>>
>>> In general, what dependencies are plugins expected to provide, and what
>>> dependencies are expected to be provided by Maven, and how are conflicts
>>> resolved in the architecture?
>>>
>>> Feel free to comment on the GitHub issue directly, or here. I'll be
>>> watching both.
>>
>> I will cite what I have written on Stack Overflow
>> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
>> holds true:
>>
>> You *never* provide a log implementation. The client application has to
>> do so. Otherwhise this would be a violation of separation of concerns.
>> Don't do any assumptions about an unknown client.
>>
>>
> I agree with that sentiment...generally. But this is a maven plugin, so I'm
> trying to figure out what Maven is going to provide it when it executes. If
> it's not going to provide an implementation, then the plugin has to. If you
> have answers to the specific questions I asked above, I think it might help.
It should not matter to you what Maven provides. It will always provide
some backend. Otherwise Maven won't be able to log itself. Even if
Maven would not provide anything. It is not your task to force some
implementation. It is a several failure of the client to do so.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: slf4j runtime dependency for plugin
Posted by Christopher <ct...@apache.org>.
On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-12 um 23:48 schrieb Christopher:
> > Hi,
> >
> > I use a plugin which has a runtime dependency on an slf4j implementation,
> > but the plugin itself is built without declaring one in its pom. (
> > https://github.com/koraktor/mavanagaiata/issues/43)
> >
> > In some versions of Maven, I get a warning about slf4j not finding an
> > implementation. In other versions, it is silent.
> >
> > Was an slf4j implementation provided in newer versions to the execution
> of
> > plugins?
> >
> > Will there be a multiple-binding conflict if the plugin itself provides
> one
> > of its own to get rid of the warning on certain versions of maven which
> > result in that warning (I didn't see one when I tried)?
> >
> > If there is a risk of a conflict, which implementation would be preferred
> > in order to converge on one provided by Maven?
> >
> > Is there another solution the plugin should seek?
> >
> > In general, what dependencies are plugins expected to provide, and what
> > dependencies are expected to be provided by Maven, and how are conflicts
> > resolved in the architecture?
> >
> > Feel free to comment on the GitHub issue directly, or here. I'll be
> > watching both.
>
> I will cite what I have written on Stack Overflow
> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> holds true:
>
> You *never* provide a log implementation. The client application has to
> do so. Otherwhise this would be a violation of separation of concerns.
> Don't do any assumptions about an unknown client.
>
>
I agree with that sentiment...generally. But this is a maven plugin, so I'm
trying to figure out what Maven is going to provide it when it executes. If
it's not going to provide an implementation, then the plugin has to. If you
have answers to the specific questions I asked above, I think it might help.
Re: slf4j runtime dependency for plugin
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-12 um 23:48 schrieb Christopher:
> Hi,
>
> I use a plugin which has a runtime dependency on an slf4j implementation,
> but the plugin itself is built without declaring one in its pom. (
> https://github.com/koraktor/mavanagaiata/issues/43)
>
> In some versions of Maven, I get a warning about slf4j not finding an
> implementation. In other versions, it is silent.
>
> Was an slf4j implementation provided in newer versions to the execution of
> plugins?
>
> Will there be a multiple-binding conflict if the plugin itself provides one
> of its own to get rid of the warning on certain versions of maven which
> result in that warning (I didn't see one when I tried)?
>
> If there is a risk of a conflict, which implementation would be preferred
> in order to converge on one provided by Maven?
>
> Is there another solution the plugin should seek?
>
> In general, what dependencies are plugins expected to provide, and what
> dependencies are expected to be provided by Maven, and how are conflicts
> resolved in the architecture?
>
> Feel free to comment on the GitHub issue directly, or here. I'll be
> watching both.
I will cite what I have written on Stack Overflow
(http://stackoverflow.com/a/7107934/696632) five years ago and it still
holds true:
You *never* provide a log implementation. The client application has to
do so. Otherwhise this would be a violation of separation of concerns.
Don't do any assumptions about an unknown client.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org