Re: FindBugs exclusion policy proposal
Possibly a vote to establish such a policy falling through. Just a hunch. On 25.02.2011 08:09:11 Glenn Adams wrote: Well then, let's make it a policy. What's preventing that? On Thu, Feb 24, 2011 at 11:07 PM, Simon Pepping spepp...@leverkruid.euwrote: As before, I will generally not fix findbugs errors or warnings in contributions by other people. I will fix findbugs errors or warnings in code that I write, or code changes that I make. Note that the use of the findbugs code analysis tool is not a policy of the FOP project, and that consequently FOP committers are not bound to use findbugs and fix its errors or warnings. Simon On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote: I think the existing exclusions should be left in trunk, and that no new ones should be permitted in (or should be fixed immediately). If you do as you suggest below, then the list of findbugs errors will just continue to grow because nobody will pay attention to them. We are at a known, stable point, we do have some exclusions that we know need fixing, and we can do that as time permits; but let's keep it that way and not backpedal by allowing in new ones. G. On Thu, Feb 24, 2011 at 8:40 AM, Andreas Delmelle andreas.delme...@telenet.be wrote: No response to any of the posts in particular, just a general thought/proposal. I can appreciate that the ComplexScripts branch requires a clean FB report so that Glenn is not continuously sent on a wild goose chase. However, personally (and Vincent seems to agree), I do not favor 'blind' exclusions just to make the warnings go away. Following the same reasoning, we could define thousands of CheckStyle suppressions, instead of encouraging people to do it correctly. I do not have a problem with looking into those issues, if no one else has the time and/or motivation, although that will not always happen _immediately_. The general idea is good, but I am wondering, given the circumstances, if we had not better invert the approach: keep the warnings alive in trunk, and add exclusions for them only in the branch. That way, devs who are not involved in the branch but do use FB, will be constantly reminded that those issues should be looked into. For the maintainer(s) of the branch, if the exclusion is properly commented, it can serve as an indication that the warning originated in trunk and has nothing to do with their changes. Should a genuine bug result from it, and it turns out to hamper the development on the branch, it can then be raised as a priority issue on this list. Ultimately, it is still a worthwhile goal to eliminate all of the warnings, but we also have to be realistic enough to admit that that will not happen overnight. WDYT? Regards, Andreas --- Jeremias Maerki
[GUMP@vmgump]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project xml-fop has an issue affecting its community integration. This issue affects 3 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - org.apache.xmlgraphics.fop : XSL-FO (Formatting Objects) processor - xml-fop : XSL-FO (Formatting Objects) processor - xml-fop-test : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/srv/gump/public/workspace/xml-fop/build/codegen-classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 49 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml package ' transcoder-package' [Working Directory: /srv/gump/public/workspace/xml-fop] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/sandbox-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xmlgraphics-commons/build/xmlgraphics-commons-25022011.jar:/s rv/gump/public/workspace/xml-batik/batik-25022011/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-gvt.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-parser.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/ batik-script.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-25022011/lib/batik-xml.jar:/srv/gump/packages/apache-attic/avalon-framework-api-4.3.jar:/srv/gump/packages/apache-attic/avalon-framework-impl-4.3.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-25022011.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.1-SNAPSHOT.jar:/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [eventResourceGenerator] Event model written to /srv/gump/public/workspace/xml-fop/build/gensrc/org/apache/fop/afp/event-model.xml [eventResourceGenerator] Event model written to
Re: AW: FOP for Large Files
Georg Datterl wrote: Which VM are you using? Mine got pretty unstable with more than 2 GB... I was running it on Windows Server 2003, 64 bit with the 64 bit Java VM. I had my heap set to about 6gb. Biggest book we did was about 1000 pages. -- View this message in context: http://old.nabble.com/FOP-for-Large-Files-tp30937374p31013059.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: FindBugs exclusion policy proposal
Did I miss seeing such a vote? Could you give me an approximate date when it occurred so I can check the archives for background? Even if it failed to obtain consensus in the past, doesn't mean it might not be accepted now. G. On Fri, Feb 25, 2011 at 4:32 AM, Jeremias Maerki d...@jeremias-maerki.chwrote: Possibly a vote to establish such a policy falling through. Just a hunch. On 25.02.2011 08:09:11 Glenn Adams wrote: Well then, let's make it a policy. What's preventing that? On Thu, Feb 24, 2011 at 11:07 PM, Simon Pepping spepp...@leverkruid.eu wrote: As before, I will generally not fix findbugs errors or warnings in contributions by other people. I will fix findbugs errors or warnings in code that I write, or code changes that I make. Note that the use of the findbugs code analysis tool is not a policy of the FOP project, and that consequently FOP committers are not bound to use findbugs and fix its errors or warnings. Simon On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote: I think the existing exclusions should be left in trunk, and that no new ones should be permitted in (or should be fixed immediately). If you do as you suggest below, then the list of findbugs errors will just continue to grow because nobody will pay attention to them. We are at a known, stable point, we do have some exclusions that we know need fixing, and we can do that as time permits; but let's keep it that way and not backpedal by allowing in new ones. G. On Thu, Feb 24, 2011 at 8:40 AM, Andreas Delmelle andreas.delme...@telenet.be wrote: No response to any of the posts in particular, just a general thought/proposal. I can appreciate that the ComplexScripts branch requires a clean FB report so that Glenn is not continuously sent on a wild goose chase. However, personally (and Vincent seems to agree), I do not favor 'blind' exclusions just to make the warnings go away. Following the same reasoning, we could define thousands of CheckStyle suppressions, instead of encouraging people to do it correctly. I do not have a problem with looking into those issues, if no one else has the time and/or motivation, although that will not always happen _immediately_. The general idea is good, but I am wondering, given the circumstances, if we had not better invert the approach: keep the warnings alive in trunk, and add exclusions for them only in the branch. That way, devs who are not involved in the branch but do use FB, will be constantly reminded that those issues should be looked into. For the maintainer(s) of the branch, if the exclusion is properly commented, it can serve as an indication that the warning originated in trunk and has nothing to do with their changes. Should a genuine bug result from it, and it turns out to hamper the development on the branch, it can then be raised as a priority issue on this list. Ultimately, it is still a worthwhile goal to eliminate all of the warnings, but we also have to be realistic enough to admit that that will not happen overnight. WDYT? Regards, Andreas --- Jeremias Maerki
Re: FindBugs exclusion policy proposal
It hasn't occurred, yet, but I expect one to happen if we were to install a new policy. I'm just predicting a possible outcome. ;-) On 25.02.2011 16:57:25 Glenn Adams wrote: Did I miss seeing such a vote? Could you give me an approximate date when it occurred so I can check the archives for background? Even if it failed to obtain consensus in the past, doesn't mean it might not be accepted now. G. On Fri, Feb 25, 2011 at 4:32 AM, Jeremias Maerki d...@jeremias-maerki.chwrote: Possibly a vote to establish such a policy falling through. Just a hunch. On 25.02.2011 08:09:11 Glenn Adams wrote: Well then, let's make it a policy. What's preventing that? On Thu, Feb 24, 2011 at 11:07 PM, Simon Pepping spepp...@leverkruid.eu wrote: As before, I will generally not fix findbugs errors or warnings in contributions by other people. I will fix findbugs errors or warnings in code that I write, or code changes that I make. Note that the use of the findbugs code analysis tool is not a policy of the FOP project, and that consequently FOP committers are not bound to use findbugs and fix its errors or warnings. Simon On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote: I think the existing exclusions should be left in trunk, and that no new ones should be permitted in (or should be fixed immediately). If you do as you suggest below, then the list of findbugs errors will just continue to grow because nobody will pay attention to them. We are at a known, stable point, we do have some exclusions that we know need fixing, and we can do that as time permits; but let's keep it that way and not backpedal by allowing in new ones. G. On Thu, Feb 24, 2011 at 8:40 AM, Andreas Delmelle andreas.delme...@telenet.be wrote: No response to any of the posts in particular, just a general thought/proposal. I can appreciate that the ComplexScripts branch requires a clean FB report so that Glenn is not continuously sent on a wild goose chase. However, personally (and Vincent seems to agree), I do not favor 'blind' exclusions just to make the warnings go away. Following the same reasoning, we could define thousands of CheckStyle suppressions, instead of encouraging people to do it correctly. I do not have a problem with looking into those issues, if no one else has the time and/or motivation, although that will not always happen _immediately_. The general idea is good, but I am wondering, given the circumstances, if we had not better invert the approach: keep the warnings alive in trunk, and add exclusions for them only in the branch. That way, devs who are not involved in the branch but do use FB, will be constantly reminded that those issues should be looked into. For the maintainer(s) of the branch, if the exclusion is properly commented, it can serve as an indication that the warning originated in trunk and has nothing to do with their changes. Should a genuine bug result from it, and it turns out to hamper the development on the branch, it can then be raised as a priority issue on this list. Ultimately, it is still a worthwhile goal to eliminate all of the warnings, but we also have to be realistic enough to admit that that will not happen overnight. WDYT? Regards, Andreas --- Jeremias Maerki Jeremias Maerki
Re: FindBugs exclusion policy proposal
ah, in that case, I wonder who would oppose a policy to use checkstyle and findbugs prior to commits in order to maintain a zero warnings state? and if opposed, then a rationale for that position? /g On Friday, February 25, 2011, Jeremias Maerki d...@jeremias-maerki.ch wrote: It hasn't occurred, yet, but I expect one to happen if we were to install a new policy. I'm just predicting a possible outcome. ;-) On 25.02.2011 16:57:25 Glenn Adams wrote: Did I miss seeing such a vote? Could you give me an approximate date when it occurred so I can check the archives for background? Even if it failed to obtain consensus in the past, doesn't mean it might not be accepted now. G. On Fri, Feb 25, 2011 at 4:32 AM, Jeremias Maerki d...@jeremias-maerki.chwrote: Possibly a vote to establish such a policy falling through. Just a hunch. On 25.02.2011 08:09:11 Glenn Adams wrote: Well then, let's make it a policy. What's preventing that? On Thu, Feb 24, 2011 at 11:07 PM, Simon Pepping spepp...@leverkruid.eu wrote: As before, I will generally not fix findbugs errors or warnings in contributions by other people. I will fix findbugs errors or warnings in code that I write, or code changes that I make. Note that the use of the findbugs code analysis tool is not a policy of the FOP project, and that consequently FOP committers are not bound to use findbugs and fix its errors or warnings. Simon On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote: I think the existing exclusions should be left in trunk, and that no new ones should be permitted in (or should be fixed immediately). If you do as you suggest below, then the list of findbugs errors will just continue to grow because nobody will pay attention to them. We are at a known, stable point, we do have some exclusions that we know need fixing, and we can do that as time permits; but let's keep it that way and not backpedal by allowing in new ones. G. On Thu, Feb 24, 2011 at 8:40 AM, Andreas Delmelle andreas.delme...@telenet.be wrote: No response to any of the posts in particular, just a general thought/proposal. I can appreciate that the ComplexScripts branch requires a clean FB report so that Glenn is not continuously sent on a wild goose chase. However, personally (and Vincent seems to agree), I do not favor 'blind' exclusions just to make the warnings go away. Following the same reasoning, we could define thousands of CheckStyle suppressions, instead of encouraging people to do it correctly. I do not have a problem with looking into those issues, if no one else has the time and/or motivation, although that will not always happen _immediately_. The general idea is good, but I am wondering, given the circumstances, if we had not better invert the approach: keep the warnings alive in trunk, and add exclusions for them only in the branch. That way, devs who are not involved in the branch but do use FB, will be constantly reminded that those issues should be looked into. For the maintainer(s) of the branch, if the exclusion is properly commented, it can Jeremias Maerki
