You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@anyware-tech.com> on 2007/08/09 20:03:53 UTC
Cannot build with JDK 1.3
Hi,
Below’s what I get when trying to build FOP with a 1.3 jdk. Does anyone
have an idea? That 1.3 build gets on my nerve...
Building with 1.4 and setting binary compatibility to 1.3 should be
sufficient, no?
Anyway, I’ve just noticed that I forgot to put the new XML Graphics
Commons jar in lib (and to update fop.bat accordingly). What’s the point
of releasing Commons first if I don’t then use it for FOP...
Vincent
--------------------------------------------------------------------------------
Buildfile: build.xml
init-avail:
[echo] ------------------- Apache FOP 0.94 [1999-2007] ----------------
[echo] See build.properties and build-local.properties for additional build settings
[echo] Apache Ant version 1.7.0 compiled on December 13 2006
[echo] VM: 1.3.1_19-b03, Sun Microsystems Inc.
[echo] JAVA_HOME: /local/home/vhennebert/Tools/Java1.3/jdk1.3.1_19/
[echo] Jimi Support PRESENT
[echo] JAI Support PRESENT
[echo] JCE Support PRESENT
[echo] JUnit Support PRESENT
[echo] XMLUnit Support PRESENT
init-filters-jdk14:
init-filters-jdk13:
[echo] Use GraphicsConfiguration adapter for JDK 1.3 or earlier.
init:
codegen:
[echo] Generating the java files from xml resources
[xslt] Processing /local/home/vhennebert/Fop/Release/Fop-0.94/src/codegen/fonts/encodings.xml to /local/home/vhennebert/Fop/Release/Fop-0.94/build/gensrc/org/apache/fop/fonts/CodePointMapping.java
[xslt] Loading stylesheet /local/home/vhennebert/Fop/Release/Fop-0.94/src/codegen/fonts/code-point-mapping.xsl
BUILD FAILED
/local/home/vhennebert/Fop/Release/Fop-0.94/build.xml:328: javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
Total time: 0 seconds
Re: Cannot build with JDK 1.3
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Christian (and all..),
It seems it could be a jdk1.3 bug related to inner classes or perhaps
static inner class methods making calls to outer static methods. I have
fixed the first junit NoSuchMethodError on ColumnNumberPropertyMaker by
converting the offending class to top-level. I will now try and work my
way through the rest of them and submit a patch.
Adrian.
Christian Geisert wrote:
> Adrian Cumiskey schrieb:
>> Hi Vincent,
>>
>> Just to confirm with you, I experienced *exactly* the same nonsensical
>> NoSuchMethodError(s) when running the junit tests. Its a strange one...
>
> Same here ... indeed very strange. One thing I noticed is that the
> "missing" methods are all in inner classes
>
> Christian
>
Re: Cannot build with JDK 1.3
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Adrian Cumiskey schrieb:
> Hi Vincent,
>
> Just to confirm with you, I experienced *exactly* the same nonsensical
> NoSuchMethodError(s) when running the junit tests. Its a strange one...
Same here ... indeed very strange. One thing I noticed is that the
"missing" methods are all in inner classes
Christian
Re: Cannot build with JDK 1.3
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Vincent,
Just to confirm with you, I experienced *exactly* the same nonsensical
NoSuchMethodError(s) when running the junit tests. Its a strange one...
Adrian.
Vincent Hennebert wrote:
> Hi Andreas,
>
> Sorry for the delay.
>
> Andreas L Delmelle a écrit :
>> On Aug 14, 2007, at 15:50, Vincent Hennebert wrote:
>>
>> Hi Adrian, Vincent,
>>
>> My eye just caught this little detail:
>>
>>>>> [2] Run ant junit-layout-standard
>>>>> Or try the column-number_non-integer.fo file in test/fotree/testcases
>>
>> This is a testcase I added, and I know the code, so can you give me the
>> exact error (which method does not exist)?
>
> You will find the relevant excerpts of the test reports attached. But
> this is quite strance since the corresponding methods are obviously
> present in the code. Moreover, I managed to make the code run within
> Eclipse with a 1.3 setup.
>
> I don’t think we can wait any longer before releasing. So I’ll prepare
> the artifacts and launch the vote in 24 hours. If you have the time to
> look at this by tomorrow that’s great and we’ll see what comes out of
> your investigation; otherwise, well, I don’t think it’s that bad to do
> it with 1.4 builds only.
>
>
> Thanks,
> Vincent
>
>
>
> ------------------------------------------------------------------------
>
> TEST-FO-tree.txt:
> -----------------
> Testcase: column-number_non-integer.fo took 0,01 sec
> Caused an ERROR
> null
> java.lang.NoSuchMethodError
> at org.apache.fop.fo.flow.TableFObj$ColumnNumberPropertyMaker.make(TableFObj.java:349)
> at org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:411)
> at org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:279)
> at org.apache.fop.fo.FObj.processNode(FObj.java:121)
> at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320)
> at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185)
> at org.xml.sax.helpers.XMLFilterImpl.startElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
> at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
> at org.apache.fop.fotreetest.FOTreeTester.runTest(FOTreeTester.java:79)
> at org.apache.fop.fotreetest.FOTreeTestSuite$FOTreeTestCase.testMain(FOTreeTestSuite.java:122)
> at org.apache.fop.fotreetest.FOTreeTestSuite$1.runTest(FOTreeTestSuite.java:101)
>
> Testcase: column-number_negative-or-zero.fo took 0,013 sec
> Caused an ERROR
> null
> java.lang.NoSuchMethodError
> at org.apache.fop.fo.flow.TableFObj$ColumnNumberPropertyMaker.make(TableFObj.java:349)
> at org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:411)
> at org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:279)
> at org.apache.fop.fo.FObj.processNode(FObj.java:121)
> at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:320)
> at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185)
> at org.xml.sax.helpers.XMLFilterImpl.startElement(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
> at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
> at org.apache.fop.fotreetest.FOTreeTester.runTest(FOTreeTester.java:79)
> at org.apache.fop.fotreetest.FOTreeTestSuite$FOTreeTestCase.testMain(FOTreeTestSuite.java:122)
> at org.apache.fop.fotreetest.FOTreeTestSuite$1.runTest(FOTreeTestSuite.java:101)
>
>
> TEST-intermediate-format.txt:
> -----------------------------
> Testcase: block_white-space-collapse_1.xml took 0,012 sec
> Caused an ERROR
> null
> java.lang.NoSuchMethodError
> at org.apache.fop.fo.flow.Character$FOCharIterator.remove(Character.java:276)
> at org.apache.fop.fo.RecursiveCharIterator.remove(RecursiveCharIterator.java:141)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:258)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:164)
> at org.apache.fop.fo.FObjMixed.endOfNode(FObjMixed.java:69)
> at org.apache.fop.fo.flow.Block.endOfNode(Block.java:145)
> at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
> at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
> at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:118)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
> at org.apache.fop.intermediate.AreaTreeParserTestCase.buildAreaTreeXML(AreaTreeParserTestCase.java:207)
> at org.apache.fop.intermediate.AreaTreeParserTestCase.setUp(AreaTreeParserTestCase.java:116)
>
> Testcase: block_white-space-collapse_2.xml took 0,01 sec
> Caused an ERROR
> null
> java.lang.NoSuchMethodError
> at org.apache.fop.fo.flow.Character$FOCharIterator.remove(Character.java:276)
> at org.apache.fop.fo.RecursiveCharIterator.remove(RecursiveCharIterator.java:141)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:285)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:164)
> at org.apache.fop.fo.FObjMixed.endOfNode(FObjMixed.java:69)
> at org.apache.fop.fo.flow.Block.endOfNode(Block.java:145)
> at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
> at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
> at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:118)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
> at org.apache.fop.intermediate.AreaTreeParserTestCase.buildAreaTreeXML(AreaTreeParserTestCase.java:207)
> at org.apache.fop.intermediate.AreaTreeParserTestCase.setUp(AreaTreeParserTestCase.java:116)
>
>
> TEST-layoutengine-standard.txt:
> -------------------------------
> Testcase: block_white-space-collapse_1.xml took 0,021 sec
> Caused an ERROR
> null
> java.lang.NoSuchMethodError
> at org.apache.fop.fo.flow.Character$FOCharIterator.remove(Character.java:276)
> at org.apache.fop.fo.RecursiveCharIterator.remove(RecursiveCharIterator.java:141)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:258)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:164)
> at org.apache.fop.fo.FObjMixed.endOfNode(FObjMixed.java:69)
> at org.apache.fop.fo.flow.Block.endOfNode(Block.java:145)
> at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
> at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
> at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:118)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
> at org.apache.fop.layoutengine.LayoutEngineTester.runTest(LayoutEngineTester.java:164)
> at org.apache.fop.layoutengine.LayoutEngineTestSuite$LayoutEngineTestCase.testMain(LayoutEngineTestSuite.java:214)
> at org.apache.fop.layoutengine.LayoutEngineTestSuite$1.runTest(LayoutEngineTestSuite.java:193)
>
> Testcase: block_white-space-collapse_2.xml took 0,024 sec
> Caused an ERROR
> null
> java.lang.NoSuchMethodError
> at org.apache.fop.fo.flow.Character$FOCharIterator.remove(Character.java:276)
> at org.apache.fop.fo.RecursiveCharIterator.remove(RecursiveCharIterator.java:141)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:285)
> at org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace(XMLWhiteSpaceHandler.java:164)
> at org.apache.fop.fo.FObjMixed.endOfNode(FObjMixed.java:69)
> at org.apache.fop.fo.flow.Block.endOfNode(Block.java:145)
> at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378)
> at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
> at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:118)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.templates.ElemCopy.execute(ElemCopy.java:114)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
> at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
> at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
> at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:709)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1284)
> at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1262)
> at org.apache.fop.layoutengine.LayoutEngineTester.runTest(LayoutEngineTester.java:164)
> at org.apache.fop.layoutengine.LayoutEngineTestSuite$LayoutEngineTestCase.testMain(LayoutEngineTestSuite.java:214)
> at org.apache.fop.layoutengine.LayoutEngineTestSuite$1.runTest(LayoutEngineTestSuite.java:193)
>
Re: Cannot build with JDK 1.3
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Adrian Cumiskey schrieb:
> Guys,
>
> Please review/try out the patch I just submitted
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=43156) and let me
> know if it fixes the MethodNotFoundError(s) on your ant junit target on
> the fop-0_94 branch when using jdk1.3.
Yes, the junit target executes now without errors - well done!
(But I don't have time to look at the patch now)
Christian
Re: Cannot build with JDK 1.3
Posted by Adrian Cumiskey <ad...@gmail.com>.
On 18/08/07, Vincent Hennebert <vi...@anyware-tech.com> wrote:
>
> Hi Andreas,
>
> Thanks for chiming in! That's exactly the comment I was needing :-)
>
> Andreas L Delmelle a écrit :
> > On Aug 17, 2007, at 18:33, Adrian Cumiskey wrote:
> >
> > Hi Adrian,
> >
> >> Please review/try out the patch I just submitted
> >> (http://issues.apache.org/bugzilla/show_bug.cgi?id=43156) and let me
> >> know if it fixes the MethodNotFoundError(s) on your ant junit target
> >> on the fop-0_94 branch when using jdk1.3.
> >
> > Although the patch solves this particular problem, I'm still wondering
> > why we should alter our codebase to ensure compatibility with buggy JDK
> > 1.3 implementations.
> >
> > I remember moving ColumnNumberPropertyMaker myself as an inner class,
> > since it's small, does not apply to anything other than table-related
> > FOs and so the related methods in the fo.flow package didn't have to
> > become part of the public API (getCurrentColumnIndex() and the like).
>
> Yes that striked my eye and I was wondering if that was a good thing.
> Apparently not.
>
> However, this doesn't mean that the patch is useless. I'll apply it to
> the 0.94 branch to be able to produce a 1.3 build. I won't merge it into
> the Trunk since we will very probably drop 1.3 support after the release
> and the code is cleaner as is.
>
> So, many thanks Adrian for your patch. The last remaining problem is
> a testcase about PDF encoding which doesn't pass (nothing excepted the
> starting "%PDF-1.4" string is output), but since I get a visually normal
> result when running it by hand I'll disable it in the branch.
> Apparently, either this is the first time anyone even tried building the
> > trunk code with JDK 1.3 or some have already done that and didn't run
> > into trouble, else we would have heard about this sooner.
> >
> > Maybe it's OK to leave this patch in existence for those foppers that
> > need 1.3 compatibility, instead of applying it to the trunk.
> >
> > No veto, just something to think about. I mean, it's not as if
> > discontinuing support for 1.3 is not the intention in the long run,
> so...
>
> I'll guess you'll be happy with my proposal? ;-)
>
> Thanks everyone,
> Vincent
>
>
Re: Cannot build with JDK 1.3
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi all,
I believe it was the introduction of the property getInstance() refactoring
which inadvertently introduced this incompatibility. I say this because all
1.3 because the unit tests all pass fine with 0.93. I totally agree with
and understand your thinking on this Andreas, but on balance I think this
minor change/patch is a quite a small price to pay for continued
1.3compatibility.
Adrian.
Re: Cannot build with JDK 1.3
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Andreas,
Thanks for chiming in! That’s exactly the comment I was needing :-)
Andreas L Delmelle a écrit :
> On Aug 17, 2007, at 18:33, Adrian Cumiskey wrote:
>
> Hi Adrian,
>
>> Please review/try out the patch I just submitted
>> (http://issues.apache.org/bugzilla/show_bug.cgi?id=43156) and let me
>> know if it fixes the MethodNotFoundError(s) on your ant junit target
>> on the fop-0_94 branch when using jdk1.3.
>
> Although the patch solves this particular problem, I'm still wondering
> why we should alter our codebase to ensure compatibility with buggy JDK
> 1.3 implementations.
>
> I remember moving ColumnNumberPropertyMaker myself as an inner class,
> since it's small, does not apply to anything other than table-related
> FOs and so the related methods in the fo.flow package didn't have to
> become part of the public API (getCurrentColumnIndex() and the like).
Yes that striked my eye and I was wondering if that was a good thing.
Apparently not.
However, this doesn’t mean that the patch is useless. I’ll apply it to
the 0.94 branch to be able to produce a 1.3 build. I won’t merge it into
the Trunk since we will very probably drop 1.3 support after the release
and the code is cleaner as is.
So, many thanks Adrian for your patch. The last remaining problem is
a testcase about PDF encoding which doesn’t pass (nothing excepted the
starting “%PDF-1.4” string is output), but since I get a visually normal
result when running it by hand I’ll disable it in the branch.
> Apparently, either this is the first time anyone even tried building the
> trunk code with JDK 1.3 or some have already done that and didn't run
> into trouble, else we would have heard about this sooner.
>
> Maybe it's OK to leave this patch in existence for those foppers that
> need 1.3 compatibility, instead of applying it to the trunk.
>
> No veto, just something to think about. I mean, it's not as if
> discontinuing support for 1.3 is not the intention in the long run, so...
I’ll guess you’ll be happy with my proposal? ;-)
Thanks everyone,
Vincent
Re: Cannot build with JDK 1.3
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 17, 2007, at 18:33, Adrian Cumiskey wrote:
Hi Adrian,
> Please review/try out the patch I just submitted (http://
> issues.apache.org/bugzilla/show_bug.cgi?id=43156) and let me know
> if it fixes the MethodNotFoundError(s) on your ant junit target on
> the fop-0_94 branch when using jdk1.3.
Although the patch solves this particular problem, I'm still
wondering why we should alter our codebase to ensure compatibility
with buggy JDK 1.3 implementations.
I remember moving ColumnNumberPropertyMaker myself as an inner class,
since it's small, does not apply to anything other than table-related
FOs and so the related methods in the fo.flow package didn't have to
become part of the public API (getCurrentColumnIndex() and the like).
Apparently, either this is the first time anyone even tried building
the trunk code with JDK 1.3 or some have already done that and didn't
run into trouble, else we would have heard about this sooner.
Maybe it's OK to leave this patch in existence for those foppers that
need 1.3 compatibility, instead of applying it to the trunk.
No veto, just something to think about. I mean, it's not as if
discontinuing support for 1.3 is not the intention in the long run,
so...
Cheers
Andreas
Re: Cannot build with JDK 1.3
Posted by Adrian Cumiskey <ad...@gmail.com>.
Guys,
Please review/try out the patch I just submitted
(http://issues.apache.org/bugzilla/show_bug.cgi?id=43156) and let me
know if it fixes the MethodNotFoundError(s) on your ant junit target on
the fop-0_94 branch when using jdk1.3.
Cheers,
Adrian.
Christian Geisert wrote:
> Vincent Hennebert schrieb:
>
> [..]
>
>> I don’t think we can wait any longer before releasing. So I’ll prepare
>
> Why?
>
>> the artifacts and launch the vote in 24 hours. If you have the time to
>> look at this by tomorrow that’s great and we’ll see what comes out of
>> your investigation; otherwise, well, I don’t think it’s that bad to do
>> it with 1.4 builds only.
>
> +1
>
> Wasn't it more or less consenus to drop 1.3 support but there has just
> been no vote on it?
> Those who really want to use FOP 0.94 with Java 1.3 (and I doubt there
> are many) can build it themselve ;-)
>
> Christian
>
Re: Cannot build with JDK 1.3
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Vincent Hennebert schrieb:
> Hi Christian,
>
> Christian Geisert a écrit :
>> Vincent Hennebert schrieb:
>>
>> [..]
>>
>>> I don’t think we can wait any longer before releasing. So I’ll prepare
>> Why?
>
> 1. because we’ve been talking about that 0.94 release for more than
> a month now, and it’s about time to actually do it;
> 2. because I’m taking vacation in one week or so and, although I’ll
> still be online, I’d like that to be handled before... Isn’t that
> a good reason? ;-)
More than good enough ;-)
> It’s not that I don’t agree with you, quite on the contrary ;-). But,
> besides the fact that we didn’t vote on dropping 1.3 support, Jeremias
> wanted a poll to be launched on fop-user to gather user opinions. I can
> understand that, and damn me for having forgotten to launch it in the
> past months, but for now it’s preferable to provide a 1.3 build if we
We'll do it immediately after the release ;-)
> can manage.
Looks good, I just did a quick test with Adrian's patch.
Christian
Re: Cannot build with JDK 1.3
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Christian,
Christian Geisert a écrit :
> Vincent Hennebert schrieb:
>
> [..]
>
>> I don’t think we can wait any longer before releasing. So I’ll prepare
>
> Why?
1. because we’ve been talking about that 0.94 release for more than
a month now, and it’s about time to actually do it;
2. because I’m taking vacation in one week or so and, although I’ll
still be online, I’d like that to be handled before... Isn’t that
a good reason? ;-)
>> the artifacts and launch the vote in 24 hours. If you have the time to
>> look at this by tomorrow that’s great and we’ll see what comes out of
>> your investigation; otherwise, well, I don’t think it’s that bad to do
>> it with 1.4 builds only.
>
> +1
>
> Wasn't it more or less consenus to drop 1.3 support but there has just
> been no vote on it?
> Those who really want to use FOP 0.94 with Java 1.3 (and I doubt there
> are many) can build it themselve ;-)
It’s not that I don’t agree with you, quite on the contrary ;-). But,
besides the fact that we didn’t vote on dropping 1.3 support, Jeremias
wanted a poll to be launched on fop-user to gather user opinions. I can
understand that, and damn me for having forgotten to launch it in the
past months, but for now it’s preferable to provide a 1.3 build if we
can manage.
Adrian, I’m looking at your patch right now.
Vincent
Re: Cannot build with JDK 1.3
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Vincent Hennebert schrieb:
[..]
> I don’t think we can wait any longer before releasing. So I’ll prepare
Why?
> the artifacts and launch the vote in 24 hours. If you have the time to
> look at this by tomorrow that’s great and we’ll see what comes out of
> your investigation; otherwise, well, I don’t think it’s that bad to do
> it with 1.4 builds only.
+1
Wasn't it more or less consenus to drop 1.3 support but there has just
been no vote on it?
Those who really want to use FOP 0.94 with Java 1.3 (and I doubt there
are many) can build it themselve ;-)
Christian
Re: Cannot build with JDK 1.3
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Andreas,
Sorry for the delay.
Andreas L Delmelle a écrit :
> On Aug 14, 2007, at 15:50, Vincent Hennebert wrote:
>
> Hi Adrian, Vincent,
>
> My eye just caught this little detail:
>
>>>>
>>>> [2] Run ant junit-layout-standard
>>>> Or try the column-number_non-integer.fo file in test/fotree/testcases
>
>
> This is a testcase I added, and I know the code, so can you give me the
> exact error (which method does not exist)?
You will find the relevant excerpts of the test reports attached. But
this is quite strance since the corresponding methods are obviously
present in the code. Moreover, I managed to make the code run within
Eclipse with a 1.3 setup.
I don’t think we can wait any longer before releasing. So I’ll prepare
the artifacts and launch the vote in 24 hours. If you have the time to
look at this by tomorrow that’s great and we’ll see what comes out of
your investigation; otherwise, well, I don’t think it’s that bad to do
it with 1.4 builds only.
Thanks,
Vincent
Re: Cannot build with JDK 1.3
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 14, 2007, at 15:50, Vincent Hennebert wrote:
Hi Adrian, Vincent,
My eye just caught this little detail:
>>>
>>> [2] Run ant junit-layout-standard
>>> Or try the column-number_non-integer.fo file in test/fotree/
>>> testcases
This is a testcase I added, and I know the code, so can you give me
the exact error (which method does not exist)?
I remember that Jeremias once corrected a mistake of mine WRT 1.3
support, when I committed code that was using 1.4-specific methods of
java.util.BitSet. Maybe I mucked this up again somehow...
Cheers
Andreas
Re: Cannot build with JDK 1.3
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Adrian,
Many thanks for looking into this. That means that I’m not entirely
crazy, or at least that I’m not the only one ;-)
I guess some changes were made in the last couple of months with broke
the 1.3 compatibility. Or our systems are simply too recent now for
running Java 1.3. I had to retrieve an old libstdc++ library that wasn’t
on my default installation...
I won’t have the time to work on the release before Thursday. If by that
time someone else manages to create 1.3 builds, all the better.
Otherwise I’ll just ship the 1.4 ones.
Cheers,
Vincent
Adrian Cumiskey a écrit :
> Hi Vincent,
>
> I spent a couple of hours yesterday trying to get it working on my
> system (Feisty Ubuntu and using Sun Java 1.3.1_20-b03). Initially I had
> a little bit of tweaking to do as ant seems to want to use
> org.apache.xml.serializer.SerializerTrace which isn't bundled with the
> default ant installation so I had to copy serializer.jar to the ant lib
> folder.
>
> Having got this working I experienced the same NoSuchMethodErrors that
> you did when I run the ant junit target. There seems to be no obvious
> reason for these errors. After this I tried to get this working I tried
> my old Windows setup (which used to build nicely with 1.3). It
> exhibited the same problem too. Very strange... if anyone else tries
> to build this I'd be interested to hear of about their experiences - and
> share the pain, so to speak ;-).
>
> Adrian.
>
> Vincent Hennebert wrote:
>> Ok, I’ve had enough. I’ve spent almost the whole day trying to build
>> a FOP distribution with Java 1.3. First trying to solve that problem of
>> Xalan not found. Then fighting to get JCE working, to finally still have
>> the corresponding testcase fail [1]. Then having cryptic
>> NoSuchMethodErrors here and there [2].
>>
>> Creating an Eclipse project and setting up a 1.3 jdk allowed me to
>> compile and run the files from [2] with no problem. Compiling from the
>> commandline failed. Running build.xml from the Eclipse project failed
>> (same error as [2]). Setting the javac.source and javac.target to 1.3 in
>> build.properties doesn’t change anything.
>>
>>
>> I’m not gonna spend my week-end on figuring out how to get a 1.3 build.
>> That’s no fun and I have plenty of other more worthy things to do on
>> FOP. I don’t need 1.3 compatibility, I’ve not even used Java 1.3 ever in
>> my life, so I really don’t care about it.
>>
>> If someone else wants to take care of the 1.3 build, I’m happy to leave
>> him holding the baby, the branch is ready to be tagged. Otherwise users
>> who need it will have to build FOP themselves from the source.
>>
>> Vincent
>>
>>
>> [1]
>> junit-basic:
>> [echo] Running basic functionality tests for fop.jar
>> [junit] Testsuite: org.apache.fop.StandardTestSuite
>> [junit] Tests run: 29, Failures: 1, Errors: 0, Time elapsed: 2,163
>> sec
>> [junit]
>> [junit] Testcase:
>> testPDFEncodingWithStandardFont(org.apache.fop.render.pdf.PDFEncodingTestCase):
>>
>> FAILED
>> [junit] 3 PDFE_TEST_MARK_ markers must be found expected:<3> but
>> was:<0>
>> [junit] junit.framework.AssertionFailedError: 3 PDFE_TEST_MARK_
>> markers must be found expected:<3> but was:<0>
>> [junit] at
>> org.apache.fop.render.pdf.PDFEncodingTestCase.checkEncoding(PDFEncodingTestCase.java:140)
>>
>> [junit] at
>> org.apache.fop.render.pdf.PDFEncodingTestCase.runTest(PDFEncodingTestCase.java:104)
>>
>> [junit] at
>> org.apache.fop.render.pdf.PDFEncodingTestCase.testPDFEncodingWithStandardFont(PDFEncodingTestCase.java:73)
>>
>> [junit]
>> [junit]
>> [junit] Test org.apache.fop.StandardTestSuite FAILED
>>
>> [2] Run ant junit-layout-standard
>> Or try the column-number_non-integer.fo file in test/fotree/testcases
Re: Cannot build with JDK 1.3
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Vincent,
I spent a couple of hours yesterday trying to get it working on my
system (Feisty Ubuntu and using Sun Java 1.3.1_20-b03). Initially I had
a little bit of tweaking to do as ant seems to want to use
org.apache.xml.serializer.SerializerTrace which isn't bundled with the
default ant installation so I had to copy serializer.jar to the ant lib
folder.
Having got this working I experienced the same NoSuchMethodErrors that
you did when I run the ant junit target. There seems to be no obvious
reason for these errors. After this I tried to get this working I tried
my old Windows setup (which used to build nicely with 1.3). It
exhibited the same problem too. Very strange... if anyone else tries
to build this I'd be interested to hear of about their experiences - and
share the pain, so to speak ;-).
Adrian.
Vincent Hennebert wrote:
> Ok, I’ve had enough. I’ve spent almost the whole day trying to build
> a FOP distribution with Java 1.3. First trying to solve that problem of
> Xalan not found. Then fighting to get JCE working, to finally still have
> the corresponding testcase fail [1]. Then having cryptic
> NoSuchMethodErrors here and there [2].
>
> Creating an Eclipse project and setting up a 1.3 jdk allowed me to
> compile and run the files from [2] with no problem. Compiling from the
> commandline failed. Running build.xml from the Eclipse project failed
> (same error as [2]). Setting the javac.source and javac.target to 1.3 in
> build.properties doesn’t change anything.
>
>
> I’m not gonna spend my week-end on figuring out how to get a 1.3 build.
> That’s no fun and I have plenty of other more worthy things to do on
> FOP. I don’t need 1.3 compatibility, I’ve not even used Java 1.3 ever in
> my life, so I really don’t care about it.
>
> If someone else wants to take care of the 1.3 build, I’m happy to leave
> him holding the baby, the branch is ready to be tagged. Otherwise users
> who need it will have to build FOP themselves from the source.
>
> Vincent
>
>
> [1]
> junit-basic:
> [echo] Running basic functionality tests for fop.jar
> [junit] Testsuite: org.apache.fop.StandardTestSuite
> [junit] Tests run: 29, Failures: 1, Errors: 0, Time elapsed: 2,163 sec
> [junit]
> [junit] Testcase:
> testPDFEncodingWithStandardFont(org.apache.fop.render.pdf.PDFEncodingTestCase):
> FAILED
> [junit] 3 PDFE_TEST_MARK_ markers must be found expected:<3> but was:<0>
> [junit] junit.framework.AssertionFailedError: 3 PDFE_TEST_MARK_
> markers must be found expected:<3> but was:<0>
> [junit] at
> org.apache.fop.render.pdf.PDFEncodingTestCase.checkEncoding(PDFEncodingTestCase.java:140)
> [junit] at
> org.apache.fop.render.pdf.PDFEncodingTestCase.runTest(PDFEncodingTestCase.java:104)
> [junit] at
> org.apache.fop.render.pdf.PDFEncodingTestCase.testPDFEncodingWithStandardFont(PDFEncodingTestCase.java:73)
> [junit]
> [junit]
> [junit] Test org.apache.fop.StandardTestSuite FAILED
>
> [2] Run ant junit-layout-standard
> Or try the column-number_non-integer.fo file in test/fotree/testcases
>
>
Re: Cannot build with JDK 1.3
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Ok, I’ve had enough. I’ve spent almost the whole day trying to build
a FOP distribution with Java 1.3. First trying to solve that problem of
Xalan not found. Then fighting to get JCE working, to finally still have
the corresponding testcase fail [1]. Then having cryptic
NoSuchMethodErrors here and there [2].
Creating an Eclipse project and setting up a 1.3 jdk allowed me to
compile and run the files from [2] with no problem. Compiling from the
commandline failed. Running build.xml from the Eclipse project failed
(same error as [2]). Setting the javac.source and javac.target to 1.3 in
build.properties doesn’t change anything.
I’m not gonna spend my week-end on figuring out how to get a 1.3 build.
That’s no fun and I have plenty of other more worthy things to do on
FOP. I don’t need 1.3 compatibility, I’ve not even used Java 1.3 ever in
my life, so I really don’t care about it.
If someone else wants to take care of the 1.3 build, I’m happy to leave
him holding the baby, the branch is ready to be tagged. Otherwise users
who need it will have to build FOP themselves from the source.
Vincent
[1]
junit-basic:
[echo] Running basic functionality tests for fop.jar
[junit] Testsuite: org.apache.fop.StandardTestSuite
[junit] Tests run: 29, Failures: 1, Errors: 0, Time elapsed: 2,163 sec
[junit]
[junit] Testcase:
testPDFEncodingWithStandardFont(org.apache.fop.render.pdf.PDFEncodingTestCase):
FAILED
[junit] 3 PDFE_TEST_MARK_ markers must be found expected:<3> but was:<0>
[junit] junit.framework.AssertionFailedError: 3 PDFE_TEST_MARK_
markers must be found expected:<3> but was:<0>
[junit] at
org.apache.fop.render.pdf.PDFEncodingTestCase.checkEncoding(PDFEncodingTestCase.java:140)
[junit] at
org.apache.fop.render.pdf.PDFEncodingTestCase.runTest(PDFEncodingTestCase.java:104)
[junit] at
org.apache.fop.render.pdf.PDFEncodingTestCase.testPDFEncodingWithStandardFont(PDFEncodingTestCase.java:73)
[junit]
[junit]
[junit] Test org.apache.fop.StandardTestSuite FAILED
[2] Run ant junit-layout-standard
Or try the column-number_non-integer.fo file in test/fotree/testcases
Re: Cannot build with JDK 1.3
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 9, 2007, at 20:03, Vincent Hennebert wrote:
> Hi,
>
> Below’s what I get when trying to build FOP with a 1.3 jdk. Does
> anyone
> have an idea? That 1.3 build gets on my nerve...
Seems like it has something to do with the fact that 1.3 didn't come
bundled with a Xalan distro yet...
> Building with 1.4 and setting binary compatibility to 1.3 should be
> sufficient, no?
I'd think so, for the binaries at least.
Then again, if we want to be absolutely certain that a 1.3 build is
still possible from the sources...?
Cheers
Andreas