That sounds good to. Its awesome that this has been done and merged and will go 
out with the next release.

Manfred

Jason Dillon wrote on 2016-06-02 21:05:

> If its on by default I would expect folks to set
> MAVEN_OPTS=-Dmaven.logging=plain instead of magically making —batch do that.
> 
> If we mutate the cli api slightly to expose more details about the cli
> configuration to the Slf4jConfiguration then regular -Dmaven.logging=plain on
> command line would probably work too.  Right now the logging configuration has
> no context of the command-line params and can only use System.properties to
> fiddle with configuration.
> 
> If ^^^ was done then could also consider adding —color={yes|no} flag, though
> I felt odd hacking that in given that this is a pluggable aspect, and if you
> were using logbook backend it would be meaningless and potentially confusing.
> 
> —jason
> 
> 
> On June 2, 2016 at 8:37:18 PM, Manfred Moser (manf...@simpligility.com) wrote:
> 
> If we plan to switch it to on be default at a later stage we could
> automatically disable it in batch mode. And tell people to run in batch mode 
> on
> a CI server.  
> 
> Just a thought..  
> 
> Manfred  
> 
> Jason van Zyl wrote on 2016-06-02 19:52:  
> 
>> If the output comes out decently in color in CI consoles then it’s probably 
>> 
>> not an issue putting the color on by default. But I haven’t checked and  
>> suggested that the color be off by default to start with.  
>>  
>>> On Jun 2, 2016, at 5:15 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:  
>>>  
>>> I merged the PR in the slf4j-gossip branch (and added a little improvement) 
>>>  
>>>  
>>> core ITs are ok (notice: ran without activating colors)  
>>> colors for Linux are not exactly the same as the screen dump: yellow from 
>>> the 
>>> 
>>> screen dump is bold white on Linux. This is ok for me  
>>>  
>>> Now, what's annoying is that:  
>>> - color is not enabled by default: I had to configure MAVEN_OPTS="-  
>>> Dmaven.logging=color"  
>>> - when redirecting content to file, color is not disabled automatically  
>>>  
>>> I don't know if this is a showstopper or not  
>>> I will continue to use it to see if there are unexpected side effects  
>>>  
>>> Regards,  
>>>  
>>> Hervé  
>>>  
>>> Le jeudi 2 juin 2016 09:21:46 Tamás Cservenák a écrit :  
>>>> Olivier, if you refer to the slf4j-gossip branch, that IMHO Jason's PR  
>>>> supersedes it.  
>>>> Will drop that branch.  
>>>>  
>>>> On Thu, Jun 2, 2016 at 8:38 AM Olivier Lamy <ol...@apache.org> wrote:  
>>>>> well I think this color stuff has already been done differently but never 
>>>>>  
>>>>> accepted......  
>>>>>  
>>>>> On 2 June 2016 at 16:28, Hervé BOUTEMY <herve.bout...@free.fr> wrote:  
>>>>>> another feature that would be great for this release:  
>>>>>> https://github.com/apache/maven/pull/81  
>>>>>>  
>>>>>> I still didn't have time to work on it, but I like the screenshot  
>>>>>> The only thing that I'd like to check is: is tty detection working? ie  
>>>>>  
>>>>> does  
>>>>>  
>>>>>> color automatically disappear if there is no tty?  
>>>>>>  
>>>>>> Regards,  
>>>>>>  
>>>>>> Hervé  
>>>>>>  
>>>>>> Le jeudi 2 juin 2016 08:23:57 Hervé BOUTEMY a écrit :  
>>>>>>> +1  
>>>>>>> this is something that was often seen: this is great that it is fixed!  
>>>>>>>  
>>>>>>> For example, the last time I published Maven core site, the build  
>>>>>  
>>>>> simply  
>>>>>  
>>>>>>> failed because of PermgenSpace: now it is working like a charm...  
>>>>>>>  
>>>>>>> This release will be a must!  
>>>>>>>  
>>>>>>> Regards,  
>>>>>>>  
>>>>>>> Hervé  
>>>>>>>  
>>>>>>> Le mercredi 1 juin 2016 20:12:33 Karl Heinz Marbaise a écrit :  
>>>>>>>> Hi Manfred,  
>>>>>>>>  
>>>>>>>> On 6/1/16 12:24 AM, Manfred Moser wrote:  
>>>>>>>>> I can feel your excitement coming through in the emails.. ;-)  
>>>>>>>>  
>>>>>>>> Of course I'm excited ;-)  
>>>>>>>>  
>>>>>>>> ...cause it's very important...I have had heard many customers  
>>>>>>>> saying  
>>>>>>>> they will not upgrade to newer versions of Maven exactly based on  
>>>>>  
>>>>> such  
>>>>>  
>>>>>>>> issue(s)...  
>>>>>>>>  
>>>>>>>> which is in general bad ...  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> This will break their argument ;-)...  
>>>>>>>>  
>>>>>>>>> Karl Heinz Marbaise wrote on 2016-05-31 15:14:  
>>>>>>>>>> Hi,  
>>>>>>>>>>  
>>>>>>>>>> tested without the patch (-Xmx6g) ...run time for the test  
>>>>>>>>>> project  
>>>>>>  
>>>>>> more  
>>>>>>  
>>>>>>>>>> than two 2 Minutes....  
>>>>>>>>>>  
>>>>>>>>>> running with the patch (-Xmx1g):  
>>>>>>>>>>  
>>>>>>>>>> Run time ca. 27 seconds...  
>>>>>>>>>>  
>>>>>>>>>> also worked with -Xmx768m ...ca. 30 seconds...  
>>>>>>>>>>  
>>>>>>>>>> so looks very good...  
>>>>>>>>>>  
>>>>>>>>>> Let us wait what the IT's say...  
>>>>>>>>>>  
>>>>>>>>>> Kind regards  
>>>>>>>>>> Karl Heinz Marbaise  
>>>>>>>>>>  
>>>>>>>>>> On 5/31/16 10:49 PM, Karl Heinz Marbaise wrote:  
>>>>>>>>>>> Hi,  
>>>>>>>>>>>  
>>>>>>>>>>> after more investigation and an extremly good tip of  
>>>>>  
>>>>> Andriy...(see  
>>>>>  
>>>>>>>>>>> MNG-6030) and in the end the solution:  
>>>>>>>>>>>  
>>>>>>>>>>> Using test project with 5000 modules just doing:  
>>>>>>>>>>>  
>>>>>>>>>>> mvn clean  
>>>>>>>>>>>  
>>>>>>>>>>> using the patch now in master  
>>>>>>>>>>> (41144e7ecf52e7ec3850f3e78d81f42f505f4af8)  
>>>>>>>>>>> extremely reduces the memory footprint...  
>>>>>>  
>>>>>> https://github.com/khmarbaise/maven-test-project-generator/blob/master  
>>>>>>  
>>>>>>>>>>> /M  
>>>>>>>>>>> aven340-with-patch-5000.png  
>>>>>>>>>>>  
>>>>>>>>>>>  
>>>>>>>>>>> This shows the result using the patch  
>>>>>>  
>>>>>>>>>>> The following shows Maven 3.3.9:  
>>>>>> https://github.com/khmarbaise/maven-test-project-generator/blob/master  
>>>>>>  
>>>>>>>>>>> /M  
>>>>>>>>>>> aven339-5000.png  
>>>>>>>>>>>  
>>>>>>>>>>>  
>>>>>>>>>>> Many thanks to Andriy for the support and help...  
>>>>>>>>>>>  
>>>>>>>>>>> we will see if not IT's will fail on the change.  
>>>>>>>>>>>  
>>>>>>>>>>>  
>>>>>>>>>>> Kind regards  
>>>>>>>>>>> Karl Heinz Marbaise  
>>>>>>>>>>>  
>>>>>>>>>>> On 4/22/16 9:49 PM, Karl Heinz Marbaise wrote:  
>>>>>>>>>>>> Hi,  
>>>>>>>>>>>>  
>>>>>>>>>>>> i started a little bit more detailed analysis..  
>>>>>>>>>>>>  
>>>>>>>>>>>> very simple via JConsole and running the different versions...  
>>>>>>>>>>>>  
>>>>>>>>>>>> I have summarized this here:  
>>>>>>>>>>>>  
>>>>>>>>>>>> https://github.com/khmarbaise/maven-test-project-generator  
>>>>>>>>>>>>  
>>>>>>>>>>>> Kind regards  
>>>>>>>>>>>> Karl Heinz Marbaise  
>>>>>>>>>>>>  
>>>>>>>>>>>> On 4/17/16 5:50 PM, Karl Heinz Marbaise wrote:  
>>>>>>>>>>>>> Hi to all,  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> i have a question concerning the memory consumption...  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> If i run maven with the same JDK and the same reactor and  
>>>>>>>>>>>>> build  
>>>>>>  
>>>>>> with  
>>>>>>  
>>>>>>>>>>>>> the  
>>>>>>>>>>>>> same parameter and plugins...  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> will the printout at the end of the build (Final Memory)  
>>>>>>  
>>>>>> something  
>>>>>>  
>>>>>>>>>>>>> realiable about the consumption of the JVM during the build  
>>>>>>  
>>>>>> ?...Or  
>>>>>>  
>>>>>>>>>>>>> is  
>>>>>>>>>>>>> it  
>>>>>>>>>>>>> at least a hint...or would i need to do something different  
>>>>>  
>>>>> (BTW:  
>>>>>>>>>>>>> Someone has a hint about that?) ...  
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> [INFO] BUILD SUCCESS  
>>>>>>>>>>>>> [INFO]  
>>>>>>  
>>>>>> --------------------------------------------------------------------  
>>>>>>  
>>>>>>>>>>>>> --  
>>>>>>>>>>>>> --  
>>>>>>>>>>>>> [INFO] Total time: 6.431 s  
>>>>>>>>>>>>> [INFO] Finished at: 2016-04-17T17:46:58+02:00  
>>>>>>>>>>>>> [INFO] Final Memory: 47M/638M  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> So if i ran the same build with different Maven versions so  
>>>>>  
>>>>> could  
>>>>>  
>>>>>>>>>>>>> this  
>>>>>>>>>>>>> give us a hint where more memory is consumed ...(to identify  
>>>>>>  
>>>>>> where  
>>>>>>  
>>>>>>>>>>>>> and  
>>>>>>>>>>>>> why is a different story)...  
>>>>>>>>>>>>>  
>>>>>>>>>>>>> Kind regards  
>>>>>>>>  
>>>>>>>> --------------------------------------------------------------------  
>>>>>>>> -  
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org  
>>>>>>>  
>>>>>>> ---------------------------------------------------------------------  
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org  
>>>>>>  
>>>>>> ---------------------------------------------------------------------  
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org  
>>>>>  
>>>>> --  
>>>>> Olivier Lamy  
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy  
>>>  
>>>  
>>> ---------------------------------------------------------------------  
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
>>> For additional commands, e-mail: dev-h...@maven.apache.org  
>>>  
>>  
>> Thanks,  
>>  
>> Jason  
>>  
>> ----------------------------------------------------------  
>> Jason van Zyl  
>> Founder, Takari and Apache Maven  
>> http://twitter.com/jvanzyl  
>> http://twitter.com/takari_io  
>> ---------------------------------------------------------  
>>  
>>  
>>  
>> ---------------------------------------------------------------------  
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
>> For additional commands, e-mail: dev-h...@maven.apache.org  
>>  
> 
> ---------------------------------------------------------------------  
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
> For additional commands, e-mail: dev-h...@maven.apache.org  
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to