Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
On 16/07/2012 14:33, Glenn Adams wrote: Hi Glenn, On Mon, Jul 16, 2012 at 5:19 AM, Chris Bowditch mailto:bowditch_ch...@hotmail.com>> wrote: I'm in favour of changing the policy to always open a Bugzilla/Jira entry for every bug fixed in FOP. However, it won't always be possible to upload resources to replicate the issue. Whilst we can clean any FO Files of senstive data we can't necessarily do the same for Images, Fonts or other confidential resources. As long as you can accept that sometimes bugs will be missing resources required to replicate the issue then I'm +1 for this policy change. BTW, I agree with this point, and I was not asking for a BZ entry that included all needed to replicate it. That has never been a requirement or goal, although, when it is possible to do so without an extraordinary effort, it is reasonable to do as a 2nd order task. I'm just looking for BZ entries (or equivalent) for substantive (non-trivial) code changes to help with tracking. I'll leave it up to the committer to decide what is substantive vs trivial. Examples of changes I would find trivial: fixing warnings (e.g., checkstyle, etc), adding/fixing javadoc or code comments, simple (non-extensive) code refactoring, cleanup, or organization. Common sense should apply. Thanks Glenn - I just wanted to make sure you were aware of that before we commit to changing the policy. I do agree with the points you've raised. I make the development teams here have a bug in place before making any code changes to FOP or otherwise so fully appreciate the benefits that brings around tracking. I'm not sure why that wasn't adopted on Apache FOP in the past, but I'm in favour of implementing it, so here's my +1 Thanks, Chris
Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
On 13/07/12 22:52, Alexios Giotis wrote: > A change log or "release notes" can be generated by Jira [1]. For example, > [2] is the release notes for Apache PDFBox 1.7. Bug or issue titles (at > least) tend to be better, if it is known that the change log is generated by > such a system. Glenn wrote very good points. It will help the FOP community > if everybody is recording in BZ or Jira substantial changes, whether this is > an existing practice or not. An automatically generated change log is definitely desirable. But we already have that with status.xml. What else does Bugzilla/JIRA bring? At the moment, adding an entry to status.xml is easy: • edit status.xml • commit it with the rest of the patch Doing it in a BTS sounds much more cumbersome to me: • loading the appropriate page in the web browser • fill in all the appropriate entries for a new bug • upload a test file illustrating the defect • click on the upload button • click several times in the ‘Open File’ dialog box to find the test file on our system • click on upload • click on enter • ... You get the idea If the end result is to have to very same change log as what is generated from status.xml right now, then I’m not sure I see the point. If the community decides to move to a BTS to log changes, I won’t oppose it but I will do it reluctantly. Also, I would be even more bothered to have to both 1) add an entry to status.xml 2) add a BZ entry. So I would suggest that we deprecate status.xml as soon as we make the move, and find a way to integrate the new change list to the website. Vincent > [1] https://confluence.atlassian.com/display/JIRA/Creating+Release+Notes > [2] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310760&version=12316940 > > Alexios Giotis > > On Jul 13, 2012, at 6:08 PM, Vincent Hennebert wrote: > >> We can decide to change that and use a bug tracking system instead, but >> in the same time we do that we will have to have in place a new >> mechanism to generate the changes [1] page. Also, we will most likely >> have to find a way to feed the BTS with the content of status.xml that >> is not there yet. >> >> [1] http://xmlgraphics.apache.org/fop/changes.html >
[Bug 53558] New: All but impossible to find the failing layout test in case of a regression
https://issues.apache.org/bugzilla/show_bug.cgi?id=53558 Priority: P2 Bug ID: 53558 Assignee: fop-dev@xmlgraphics.apache.org Summary: All but impossible to find the failing layout test in case of a regression Severity: normal Classification: Unclassified OS: All Reporter: jerem...@apache.org Hardware: All Status: NEW Version: 1.1dev Component: page-master/layout Product: Fop Since the unit tests were changed to JUnit 4, a failing layout engine test is no longer identifiable, since the individual tests just have an index but no name. I currently get: Testcase: runTest[555] took 0.017 sec Testcase: runTest[556] took 0.022 sec Testcase: runTest[557] took 0.023 sec Testcase: runTest[558] took 0.037 sec Testcase: runTest[559] took 0.032 sec Caused an ERROR Expected XPath expression to evaluate to 'true', but got 'false' (XPath: boolean(/areaTree/*)) java.lang.RuntimeException: Expected XPath expression to evaluate to 'true', but got 'false' (XPath: boolean(/areaTree/*)) at org.apache.fop.layoutengine.TrueCheck.doCheck(TrueCheck.java:78) at org.apache.fop.layoutengine.TrueCheck.check(TrueCheck.java:59) at org.apache.fop.layoutengine.LayoutEngineTestCase.doATChecks(LayoutEngineTestCase.java:256) at org.apache.fop.layoutengine.LayoutEngineTestCase.checkAll(LayoutEngineTestCase.java:190) at org.apache.fop.layoutengine.LayoutEngineTestCase.runTest(LayoutEngineTestCase.java:171) Testcase: runTest[560] took 0.021 sec Testcase: runTest[561] took 0.022 sec Testcase: runTest[562] took 0.023 sec -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53558] All but impossible to find the failing layout test in case of a regression
https://issues.apache.org/bugzilla/show_bug.cgi?id=53558 Vincent Hennebert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Vincent Hennebert --- This is a known issue of JUnit 4. However, rev. 1360665 contains a change to LayoutEngineTestUtils that will display the list of correspondences between test number and test files by switching the DEBUG boolean to true. I believe this provides a reasonable solution to this issue, feel free to re-open if not. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53558] All but impossible to find the failing layout test in case of a regression
https://issues.apache.org/bugzilla/show_bug.cgi?id=53558 Glenn Adams changed: What|Removed |Added Priority|P2 |P3 Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Glenn Adams --- I agree with Jeremias on this, and further, that something else needs to be done to better report the failing test without having to do something special (i.e., switching a DEBUG boolean). I reported this problem just after JUnit 4 was adopted, and I seem to recall that Mehdi was going to look into a better solution. FWIW, when I encounter this problem, I've been using Eclipse to catch the assert, which then allows one to discover the culprit by walking up the stack a few levels. In any case, I'm reopening this (as P3) as I'd like to see a better, long-term solution. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53558] All but impossible to find the failing layout test in case of a regression
https://issues.apache.org/bugzilla/show_bug.cgi?id=53558 --- Comment #3 from Mehdi Houshmand --- Hmm... I swear I replied to this this morning... Anyways, I have been looking into this periodically and hadn't found anything 'til today: https://github.com/KentBeck/junit/issues/44 I don't have time to look into this at the moment, but I will look into it in the next week or so so watch this space. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53560] New: 1.1rc1 The file format is not supported. No ImagePreloader found.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53560 Priority: P2 Bug ID: 53560 Assignee: fop-dev@xmlgraphics.apache.org Summary: 1.1rc1 The file format is not supported. No ImagePreloader found. Severity: normal Classification: Unclassified Reporter: f.bo...@genkgo.nl Hardware: PC Status: NEW Version: 1.1dev Component: images Product: Fop System: - debian squeeze - openjdk - tomcat6 - fop 1.1 rc1 - attached the servlet First, build fop 1.0 from source with ant and deployed fop.war to tomcat6. Had problems, see https://bugs.launchpad.net/ubuntu/+source/fop/+bug/268930. Copying xml-apis-ext.jar to /var/lib/tomcat6/webapps/fop/WEB-INF/lib/ fixed the problem. Then, upgrading to fop 1.1rc1, also built from source, keeps saying: Image not available. URI: [file]. Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format is not supported. No ImagePreloader found for [file] I feel that this is a build or dependency problem, because all libraries are in place. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53560] 1.1rc1 The file format is not supported. No ImagePreloader found.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53560 Glenn Adams changed: What|Removed |Added Status|NEW |NEEDINFO OS||All --- Comment #1 from Glenn Adams --- The first question you should ask yourself is "did I provide all the essential information to understand this bug?" Unfortunately, you fail to provide any information on what kind of image file format is a problem, you fail to provide an input FO test file, you fail to provide a console output. In other words, you failed to create a meaningful bug report. I should just mark this bug as INVALID, but instead I'll mark it as NEEDINFO. Please read [1] before you proceed further. [1] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- You are receiving this mail because: You are the assignee for the bug.
Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
Hi Vincent, On Jul 17, 2012, at 12:10 PM, Vincent Hennebert wrote: > On 13/07/12 22:52, Alexios Giotis wrote: >> A change log or "release notes" can be generated by Jira [1]. For example, >> [2] is the release notes for Apache PDFBox 1.7. Bug or issue titles (at >> least) tend to be better, if it is known that the change log is generated by >> such a system. Glenn wrote very good points. It will help the FOP community >> if everybody is recording in BZ or Jira substantial changes, whether this is >> an existing practice or not. > > An automatically generated change log is definitely desirable. But we > already have that with status.xml. What else does Bugzilla/JIRA bring? It improves documentation. For example, I frequently execute "svn annotate", read the usually brief commit message and then refer to the bug for more info (and context in my case). I don't like the fact that I have to rely to another system, but it helps, especially for old change sets. > At the moment, adding an entry to status.xml is easy: > • edit status.xml > • commit it with the rest of the patch > > Doing it in a BTS sounds much more cumbersome to me: > • loading the appropriate page in the web browser > • fill in all the appropriate entries for a new bug > • upload a test file illustrating the defect > • click on the upload button > • click several times in the ‘Open File’ dialog box to find the test >file on our system > • click on upload > • click on enter > • ... You get the idea Yes, filing a bug is definitely much more cumbersome than updating status.xml and nobody would like wasting the time of the few experienced developers. But I expect it will take less than 15 minutes to file a bug and that this time should be small compared to the time spend to make a substantive change. Small improvements, javadoc updates, typo fixes, renaming of variables, checkstyle / findbug fixes ... don't deserve a new bug. Test files illustrating the defect are not mandatory and in most cases, they are committed as part of the unit tests (which are also not mandatory as well but good to have). > > If the end result is to have to very same change log as what is > generated from status.xml right now, then I’m not sure I see the point. The end result is to provide a documentation trail. I initially replied to this thread because Jira is not (yet) used in FOP and it happens to provide this feature. > > If the community decides to move to a BTS to log changes, I won’t oppose > it but I will do it reluctantly. Also, I would be even more bothered to > have to both 1) add an entry to status.xml 2) add a BZ entry. So I would > suggest that we deprecate status.xml as soon as we make the move, and > find a way to integrate the new change list to the website. You are right about deprecating status.xml. I hope that in the long term you will see the benefits of this practice and willingly file bugs (BZ) or create issues (Jira). Alexios > > > Vincent > > >> [1] https://confluence.atlassian.com/display/JIRA/Creating+Release+Notes >> [2] >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310760&version=12316940 >> >> Alexios Giotis >> >> On Jul 13, 2012, at 6:08 PM, Vincent Hennebert wrote: >> >>> We can decide to change that and use a bug tracking system instead, but >>> in the same time we do that we will have to have in place a new >>> mechanism to generate the changes [1] page. Also, we will most likely >>> have to find a way to feed the BTS with the content of status.xml that >>> is not there yet. >>> >>> [1] http://xmlgraphics.apache.org/fop/changes.html >> >
Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
On Tue, Jul 17, 2012 at 6:05 PM, Alexios Giotis wrote: > The end result is to provide a documentation trail. I initially replied to > this thread because Jira is not (yet) used in FOP and it happens to provide > this feature. FYI, Alex, if you aren't aware of it, the project has already voted to move to JIRA, and we are awaiting the infrastructure group to perform the conversion. [1] [1] https://issues.apache.org/jira/browse/INFRA-4800
