[GitHub] maven-plugins pull request: Log level fix for ProjectUtils.
GitHub user UltimaPhoenix opened a pull request: https://github.com/apache/maven-plugins/pull/20 Log level fix for ProjectUtils. This patch fixes the log level and distinguishes the exceptional case. With the previous code, when, for example, 'GitHub' is configured in pom.xml as issueManagement system, during the execution of the 'mvn site' goal, while the plugin starts generating report, it prompts two error lines for 'Trac' and 'JIRA' even without configuration errors. You can merge this pull request into a Git repository by running: $ git pull https://github.com/UltimaPhoenix/maven-plugins trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/20.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #20 commit 4097b34ee62efa75a9cbe4a0f9aaeebc632486ee Author: UltimaPhoenix fabio.gru...@gmail.com Date: 2014-05-05T08:42:33Z Log level fix for ProjectUtils. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Thoughts on MNG-5626 and the need for a log file
One thing that I like about Eclipse is that it contains a log file to capture the unexpected warning or error. These warnings or errors may not kill the program but at least I can peer inside to see what's going on. With regard to MNG-5626, it makes me wonder should Maven have a default logging location. There are situations that shouldn't kill a build (like negative build times) but are extraordinary enough that they should be dumped to a log file for studying. I think plugins should have the ability to do such things for the sake of diagnosing out unfavorable conditions/bugs in the code. BTW, this is a different feature than debug info and stack traces. I don't want to bug the user with more on their screen. I just want normal builds to run like they do except introduce a warning log. Thoughts? Cheers, Paul
[FYI] maven-scm-plugin IT is failing since Feb 25
https://builds.apache.org/job/maven-scm/ Thanks -D
Re: [FYI] maven-scm-plugin IT is failing since Feb 25
change list https://builds.apache.org/job/maven-scm/changes -D On Mon, May 5, 2014 at 9:01 AM, Dan Tran dant...@gmail.com wrote: https://builds.apache.org/job/maven-scm/ Thanks -D
Re: Thoughts on MNG-5626 and the need for a log file
Am 2014-05-05 16:20, schrieb Paul Benedict: One thing that I like about Eclipse is that it contains a log file to capture the unexpected warning or error. These warnings or errors may not kill the program but at least I can peer inside to see what's going on. With regard to MNG-5626, it makes me wonder should Maven have a default logging location. There are situations that shouldn't kill a build (like negative build times) but are extraordinary enough that they should be dumped to a log file for studying. I think plugins should have the ability to do such things for the sake of diagnosing out unfavorable conditions/bugs in the code. BTW, this is a different feature than debug info and stack traces. I don't want to bug the user with more on their screen. I just want normal builds to run like they do except introduce a warning log. Paul, how would a log file help to solve the above mentioned problem (MNG-5626). I guess Logback relies on currentMillis too. Moreover, what should be logged and to what extent? I do think, it's worth investigating but quite hard to decide what should be printed to such a file. Using SLF4J markers and a distinct Logback configuration may be a good help. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-5626 and the need for a log file
In the instance of MNG-5256, the log file could dump the values that go into calculating a negative build time. I think that would be very insightful to trace the root cause. What should be logged? Warnings. I actually would propose exceptions too because them on the screen only help if you have logging like a Hudson instance to view them. Paul Cheers, Paul On Mon, May 5, 2014 at 1:49 PM, Michael Osipov micha...@apache.org wrote: Am 2014-05-05 16:20, schrieb Paul Benedict: One thing that I like about Eclipse is that it contains a log file to capture the unexpected warning or error. These warnings or errors may not kill the program but at least I can peer inside to see what's going on. With regard to MNG-5626, it makes me wonder should Maven have a default logging location. There are situations that shouldn't kill a build (like negative build times) but are extraordinary enough that they should be dumped to a log file for studying. I think plugins should have the ability to do such things for the sake of diagnosing out unfavorable conditions/bugs in the code. BTW, this is a different feature than debug info and stack traces. I don't want to bug the user with more on their screen. I just want normal builds to run like they do except introduce a warning log. Paul, how would a log file help to solve the above mentioned problem (MNG-5626). I guess Logback relies on currentMillis too. Moreover, what should be logged and to what extent? I do think, it's worth investigating but quite hard to decide what should be printed to such a file. Using SLF4J markers and a distinct Logback configuration may be a good help. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-5626 and the need for a log file
Am Mon, 5 May 2014 14:17:50 -0500 schrieb Paul Benedict pbened...@apache.org: What should be logged? Warnings. I actually would propose exceptions too because them on the screen only help if you have logging like a Hudson instance to view them. Uh, what is wrong with mvn -X -l? Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-5626 and the need for a log file
-X is debug/stack traces, right? That's great when you want a slosh-load of debug information, but that's only useful when you're looking for a problem. There's no recourse when problems oddball conditions occur with -X not enabled. My point is Maven and Maven plugins should be able to log those abnormal conditions in the course of a normal build. We shouldn't have to dump the world -- especially when the problem is not always repeatable. Cheers, Paul On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels e...@zusammenkunft.netwrote: Am Mon, 5 May 2014 14:17:50 -0500 schrieb Paul Benedict pbened...@apache.org: What should be logged? Warnings. I actually would propose exceptions too because them on the screen only help if you have logging like a Hudson instance to view them. Uh, what is wrong with mvn -X -l? Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-5626 and the need for a log file
Sorry I was not clear, what I was trying to say is: maven has logging built in, if you need a logfile you can pass the -l switch or re-configure slf4j. It also has some control over the loglevel (-X). Most users dont need it because they (think CI Server) just catch stdout. http://maven.apache.org/maven-logging.html Gruss Bernd Am Mon, 5 May 2014 15:14:33 -0500 schrieb Paul Benedict pbened...@apache.org: -X is debug/stack traces, right? That's great when you want a slosh-load of debug information, but that's only useful when you're looking for a problem. There's no recourse when problems oddball conditions occur with -X not enabled. My point is Maven and Maven plugins should be able to log those abnormal conditions in the course of a normal build. We shouldn't have to dump the world -- especially when the problem is not always repeatable. Cheers, Paul On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels e...@zusammenkunft.netwrote: Am Mon, 5 May 2014 14:17:50 -0500 schrieb Paul Benedict pbened...@apache.org: What should be logged? Warnings. I actually would propose exceptions too because them on the screen only help if you have logging like a Hudson instance to view them. Uh, what is wrong with mvn -X -l? Gruss Bernd - 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
Re: [VOTE] Release Apache Maven Plugin Tools version 3.3
+1 On Mon, May 5, 2014 at 2:27 AM, Olivier Lamy olamy-at-apache.org |dev@maven.apache.org/Allow_neo-media| p9bp75e...@sneakemail.com wrote: +1 On 4 May 2014 05:50, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, We solved 23 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=18959 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1022/ http://repository.apache.org/content/repositories/maven-1022/org/apache/maven/plugin-tools/maven-plugin-tools/3.3/maven-plugin-tools-3.3-source-release.zip Source release checksum(s): maven-plugin-tools-3.3-source-release.zip sha1: 1aea63ada21b9f510813ce36d9b249f19977b5bb Staging site: http://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Plugin Tools version 3.3
+1 On Mon, May 5, 2014 at 2:27 AM, Olivier Lamy olamy-at-apache.org |dev@maven.apache.org/Allow_neo-media| p9bp75e...@sneakemail.com wrote: +1 On 4 May 2014 05:50, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, We solved 23 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=18959 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139status=1 Staging repo: https://repository.apache.org/content/repositories/maven-1022/ http://repository.apache.org/content/repositories/maven-1022/org/apache/maven/plugin-tools/maven-plugin-tools/3.3/maven-plugin-tools-3.3-source-release.zip Source release checksum(s): maven-plugin-tools-3.3-source-release.zip sha1: 1aea63ada21b9f510813ce36d9b249f19977b5bb Staging site: http://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [FYI] maven-scm-plugin IT is failing since Feb 25
seems related to SCM-741: the IT added contains a copy of .svn content taken from svn 1.7 (format 29), and I suppose Jenkins uses svn 1.8 which has a different one (format 31) don't know how wa can improve the IT to be more tolerant to svn version updates Regards, Hervé Le lundi 5 mai 2014 09:03:37 Dan Tran a écrit : change list https://builds.apache.org/job/maven-scm/changes -D On Mon, May 5, 2014 at 9:01 AM, Dan Tran dant...@gmail.com wrote: https://builds.apache.org/job/maven-scm/ Thanks -D - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [FYI] maven-scm-plugin IT is failing since Feb 25
Looks like we stuck without a new snapshot until this is fixed!! -D On Mon, May 5, 2014 at 6:49 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: seems related to SCM-741: the IT added contains a copy of .svn content taken from svn 1.7 (format 29), and I suppose Jenkins uses svn 1.8 which has a different one (format 31) don't know how wa can improve the IT to be more tolerant to svn version updates Regards, Hervé Le lundi 5 mai 2014 09:03:37 Dan Tran a écrit : change list https://builds.apache.org/job/maven-scm/changes -D On Mon, May 5, 2014 at 9:01 AM, Dan Tran dant...@gmail.com wrote: https://builds.apache.org/job/maven-scm/ Thanks -D - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
