Re: junit tests in nightly builds [was: Re: Solving FindBugs issue]
BTW, if someone would bother to nominate me as a committer, I would be happy to do this work directly. I don't like depending on the other committers to make progress in this area any more than you like having to address it. G. On Wed, Feb 23, 2011 at 1:15 AM, Glenn Adams wrote: > OK, understand on the junit headless issue. For checkstyle/findbugs it > would be useful to fail the nightly build if they do not pass. I will > investigate the necessary changes to enable this option, which I hope can be > adopted. > > G. > > > On Wed, Feb 23, 2011 at 12:55 AM, Simon Pepping wrote: > >> On Tue, Feb 22, 2011 at 11:25:20AM -0700, Glenn Adams wrote: >> > I notice also that the nightly build target does not run all the junit >> > tests. It would be better if it run all of them plus checkstyle and >> > findbugs. >> >> Many junit tests require a display. Nightly builds are run in a >> headless configuration, hence I had to disable many junit tests. At >> nightly builds there is no one to check checkstyle and findbugs errors >> and warnings; therefore there is no point in running them. >> >> Simon >> > >
Re: junit tests in nightly builds [was: Re: Solving FindBugs issue]
OK, understand on the junit headless issue. For checkstyle/findbugs it would be useful to fail the nightly build if they do not pass. I will investigate the necessary changes to enable this option, which I hope can be adopted. G. On Wed, Feb 23, 2011 at 12:55 AM, Simon Pepping wrote: > On Tue, Feb 22, 2011 at 11:25:20AM -0700, Glenn Adams wrote: > > I notice also that the nightly build target does not run all the junit > > tests. It would be better if it run all of them plus checkstyle and > > findbugs. > > Many junit tests require a display. Nightly builds are run in a > headless configuration, hence I had to disable many junit tests. At > nightly builds there is no one to check checkstyle and findbugs errors > and warnings; therefore there is no point in running them. > > Simon >
junit tests in nightly builds [was: Re: Solving FindBugs issue]
On Tue, Feb 22, 2011 at 11:25:20AM -0700, Glenn Adams wrote: > I notice also that the nightly build target does not run all the junit > tests. It would be better if it run all of them plus checkstyle and > findbugs. Many junit tests require a display. Nightly builds are run in a headless configuration, hence I had to disable many junit tests. At nightly builds there is no one to check checkstyle and findbugs errors and warnings; therefore there is no point in running them. Simon
Re: Assertions in junit tests [was: Re: Solving FindBugs issue]
I support enabling assertions by default on junit tests. More testing is a good thing. G. On Tue, Feb 22, 2011 at 3:40 PM, Andreas Delmelle < andreas.delme...@telenet.be> wrote: > On 22 Feb 2011, at 19:25, Andreas Delmelle wrote: > > > One way to enable assertions I found so far, and that seems to work: > > - use fork="true" on the target > > - insert: in that target > > > > That seems to yield the expected behavior at first glance. Our junit > targets are not forked, however. Not sure if that is preferable... > > FWIW, having configured this on the junit-layout-standard target, yields > one AssertionError > > [junit] Testcase: > block-container_reference-orientation_bug36391.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): >Caused an ERROR > [junit] null > [junit] java.lang.AssertionError > [junit] at > org.apache.fop.layoutmgr.BreakingAlgorithm.getLineWidth(BreakingAlgorithm.java:1394) > > ... > > > For the remainder, all layout tests pass. > > > Regards, > > Andreas > --- > >
Re: Assertions in junit tests [was: Re: Solving FindBugs issue]
On 22 Feb 2011, at 19:25, Andreas Delmelle wrote: > One way to enable assertions I found so far, and that seems to work: > - use fork="true" on the target > - insert: in that target > > That seems to yield the expected behavior at first glance. Our junit targets > are not forked, however. Not sure if that is preferable... FWIW, having configured this on the junit-layout-standard target, yields one AssertionError [junit] Testcase: block-container_reference-orientation_bug36391.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1): Caused an ERROR [junit] null [junit] java.lang.AssertionError [junit] at org.apache.fop.layoutmgr.BreakingAlgorithm.getLineWidth(BreakingAlgorithm.java:1394) ... For the remainder, all layout tests pass. Regards, Andreas ---
Re: Solving FindBugs issue
Since the FOP project itself does not use any IDE for builds, then the ANT build process should be considered the standard process for compilation, junit tests, checkstyle tests, findbugs tests, etc. I always run: ant clean junit checkstyle findbugs in order to verify no reported errors before I commit a change. I notice also that the nightly build target does not run all the junit tests. It would be better if it run all of them plus checkstyle and findbugs. G. On Tue, Feb 22, 2011 at 12:34 AM, Simon Pepping wrote: > When I build the project or part of it with Eclipse, and run findbugs > afterwards (with ant), I get a number of errors. Now I always make a > clean compile before running findbugs. I do not understand why Eclipse > builds would create findbugs errors where a clean ant build does not. > It makes findbugs seem fickle. > > I just tested it. With 'ant clean findbugs' I get 0 errors and > warnings. With eclipse clean and build project, I get 23 low priority > warnings. > > Simon > > On Mon, Feb 21, 2011 at 12:58:06PM -0700, Glenn Adams wrote: > > The current trunk shows no warnings during ANT compile. Please make > > reference to the current trunk/HEAD as 1.0 is published and history at > this > > time. > > > > It's a different matter with certain IDEs, e.g., Eclipse, which set their > > warning levels to a more sensitive level than the ANT build. > > > > Although it would be nice to eliminate such additional warnings, it is > not > > as high priority IMO as ensuring that new compile, checkstyle, or > findbugs > > warnings/errors do not appear during ANT builds. At the same time, > warnings > > that do appear should not automatically be excluded without careful, > manual > > review. > > > > G. > > > > On Mon, Feb 21, 2011 at 12:49 PM, Eric Douglas >wrote: > > > > > I haven't looked at the trunk lately but 1.0 has a ton of warnings, at > > > least in my compile. > > > I don't know how much warnings have changed over the versions. > > > I think it was originally written to compile on Java 1.4 or maybe even > > > 1.3. > > > 1.5 shows thousands of warnings, 1.6 shows more. > > > Some of the warnings are quirky (raw type list?), some are just > wasteful > > > (dead code? Local variable never referenced?). > > > If there's code which is actually incorrect logic it needs to be fixed. > > > If there's code which is just incomplete logic, maybe setting something > > > up for a future improvement someone wanted to add, that should be > > > removed and placed in a separate to do list document. >
Re: Assertions in junit tests [was: Re: Solving FindBugs issue]
On 22 Feb 2011, at 19:04, Andreas Delmelle wrote: > On 22 Feb 2011, at 08:50, Simon Pepping wrote: >> It would be nice if assertions were checked during the junit tests. >> However, when I set: , I get >> junit.framework.AssertionFailedError errors. How can this be done? > > Sounds like a good idea. > IIC, simply using "-ea" would enable internal assertions for JUnit's classes > as well. > You probably want something like "-ea:org.apache.fop..." to make sure only > assertions in FOP's code are taken into account. Tried that and failed.. :( One way to enable assertions I found so far, and that seems to work: - use fork="true" on the target - insert: in that target That seems to yield the expected behavior at first glance. Our junit targets are not forked, however. Not sure if that is preferable... Regards, Andreas ---
Re: Solving FindBugs issue
On 22 Feb 2011, at 08:34, Simon Pepping wrote: > When I build the project or part of it with Eclipse, and run findbugs > afterwards (with ant), I get a number of errors. Now I always make a > clean compile before running findbugs. I do not understand why Eclipse > builds would create findbugs errors where a clean ant build does not. > It makes findbugs seem fickle. I seem to have the reverse issue here: the Ant target yielded warnings that the FB plugin for IntelliJ IDEA does not complain about (same FB version, same exclusion file)... Maybe the developers of those plugins were not using FindBugs themselves. ;-) Regards, Andreas ---
Re: Assertions in junit tests [was: Re: Solving FindBugs issue]
On 22 Feb 2011, at 08:50, Simon Pepping wrote: > On Mon, Feb 21, 2011 at 08:28:33PM +0100, Andreas Delmelle wrote: >> I saw one exclusion --unconfirmed cast-- that would seem to stem from my >> recent refactoring in the BlockStackingLMs. Not sure why an exclusion was >> chosen here, but adding an assert statement in the code avoids the warning >> as well *and* has the benefit of being visible exactly at the spot in the >> code where it applies. Seemed like the more proper way to handle this. > > It would be nice if assertions were checked during the junit tests. > However, when I set: , I get > junit.framework.AssertionFailedError errors. How can this be done? Sounds like a good idea. IIC, simply using "-ea" would enable internal assertions for JUnit's classes as well. You probably want something like "-ea:org.apache.fop..." to make sure only assertions in FOP's code are taken into account. Regards, Andreas ---
Re: Assertions in junit tests [was: Re: Solving FindBugs issue]
On Mon, Feb 21, 2011 at 08:28:33PM +0100, Andreas Delmelle wrote: > I saw one exclusion --unconfirmed cast-- that would seem to stem from my > recent refactoring in the BlockStackingLMs. Not sure why an exclusion was > chosen here, but adding an assert statement in the code avoids the warning as > well *and* has the benefit of being visible exactly at the spot in the code > where it applies. Seemed like the more proper way to handle this. It would be nice if assertions were checked during the junit tests. However, when I set: , I get junit.framework.AssertionFailedError errors. How can this be done? Simon
Re: Solving FindBugs issue
When I build the project or part of it with Eclipse, and run findbugs afterwards (with ant), I get a number of errors. Now I always make a clean compile before running findbugs. I do not understand why Eclipse builds would create findbugs errors where a clean ant build does not. It makes findbugs seem fickle. I just tested it. With 'ant clean findbugs' I get 0 errors and warnings. With eclipse clean and build project, I get 23 low priority warnings. Simon On Mon, Feb 21, 2011 at 12:58:06PM -0700, Glenn Adams wrote: > The current trunk shows no warnings during ANT compile. Please make > reference to the current trunk/HEAD as 1.0 is published and history at this > time. > > It's a different matter with certain IDEs, e.g., Eclipse, which set their > warning levels to a more sensitive level than the ANT build. > > Although it would be nice to eliminate such additional warnings, it is not > as high priority IMO as ensuring that new compile, checkstyle, or findbugs > warnings/errors do not appear during ANT builds. At the same time, warnings > that do appear should not automatically be excluded without careful, manual > review. > > G. > > On Mon, Feb 21, 2011 at 12:49 PM, Eric Douglas wrote: > > > I haven't looked at the trunk lately but 1.0 has a ton of warnings, at > > least in my compile. > > I don't know how much warnings have changed over the versions. > > I think it was originally written to compile on Java 1.4 or maybe even > > 1.3. > > 1.5 shows thousands of warnings, 1.6 shows more. > > Some of the warnings are quirky (raw type list?), some are just wasteful > > (dead code? Local variable never referenced?). > > If there's code which is actually incorrect logic it needs to be fixed. > > If there's code which is just incomplete logic, maybe setting something > > up for a future improvement someone wanted to add, that should be > > removed and placed in a separate to do list document.
