Rather than a general solution about modifying the logger, I wonder if
there's just something the invoker:install goal could do to resolve /
copy these differently, so that it can have an option to be less
verbose in that specific mojo.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, Jun 12, 2015 at 12:33 PM, Robert Scholte <[email protected]> wrote:
> I still have this wish to be able to change the logging for one specific
> plugin from commandline, but that's still not possible (there are already
> several threads about it on this dev-list).
> The reason is that on startup the decision has already been made with
> LoggerFactory to use. You can't change the logging level during runtime for
> already instantiated classes, in this case some Aether specific classes.
>
> So up until now there are just 2 options: define the preferred logging
> levels up front or start a new JVM with the preferred logging levels. The
> last option explains why the maven-invoker-plugin can have a different
> logging level compared to the started Maven execution.
>
> thanks,
> Robert
>
> Op Fri, 12 Jun 2015 00:06:09 +0200 schreef Christopher
> <[email protected]>:
>
>
>> Hi,
>>
>> Thanks for the suggestion. I'm not sure it's sufficient, though,
>> because (assuming that works) it seems like it would also suppress
>> messages I want to see. I really only want it to suppress the messages
>> during the invoker:install task, and not any other time.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Wed, Jun 10, 2015 at 3:16 PM, Robert Scholte <[email protected]>
>> wrote:
>>>
>>> Hi,
>>>
>>> AFAIK it is Aether which is responsible for these messages.
>>> If you use M3.1.1 or above, you can change the logging of
>>> conf/logging/simplelogger.properties
>>>
>>> Based on http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html I
>>> would
>>> expect this to work:
>>> org.slf4j.simpleLogger.log.org.sonatype.aether = warn
>>> org.slf4j.simpleLogger.log.org.eclipse.aether = warn
>>>
>>> Since this logging is still done by the main executor of Maven (and not
>>> by
>>> the forked executor from the invoker-plugin) this seems to be your best
>>> option.
>>>
>>> thanks,
>>> Robert
>>>
>>> Op Wed, 10 Jun 2015 02:08:01 +0200 schreef Christopher
>>> <[email protected]>:
>>>
>>>> Hi,
>>>>
>>>> I have a maven plugin which has some ITs which are executed using the
>>>> recommended way using the maven-invoker-plugin. However, the
>>>> invoker:install goal always spams my build server's logs with
>>>> "Downloading" messages, copying from my local repo to a location I
>>>> specify under target/.
>>>>
>>>> I absolutely cannot figure out a way to suppress this output. It is
>>>> spammy, and happens every build (because it's not going to the local
>>>> repo, for the reasons described in the plugin docs). And, I really
>>>> don't care that it copied something from my local repo to this
>>>> directory in target/ being logged at the INFO level.
>>>>
>>>> What's the best solution to work towards? I don't think there is one
>>>> now, but if one were to be created, what would it look like?
>>>>
>>>> The ideas I thought of so far:
>>>>
>>>> 1. add <silent>true</silent> option on the install goal
>>>> 2. add <log>filename</log> option on the install goal
>>>> 3. some manipulation of the logger configuration to hide logs from this
>>>> plugin
>>>> 4. since this is a common task before running ITs for plugins, it
>>>> could be baked in to the integration-test goal, and automatically
>>>> suppressed
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

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

Reply via email to