[GUMP@brutus]: 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 [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://brutus.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: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.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: 30 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-28112004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-28112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-28112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-28112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-28112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-28112004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-28112004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - junit: [javac] Compiling 31 source files to /home/gump/workspaces2/public/workspace/xml-fop/build/test-classes [javac] This version of java does not support the classic compiler; upgrading to modern [javac]
Re: Preview for a general XSL-FO processing API
Hi Victor On 27.11.2004 16:53:54 Victor Mote wrote: I looked at the doc, and I think this is all pretty useful. I'd like to spend some more time on it later, and I think I will probably write a FOray implementation after I get 0.2 released. Here are some preliminary thoughts: I finally downloaded the Foray code yesterday because I thought it might be fun to write that implementation already. I didn't invest a lot of time but I got confused about the mixture of Foray and FOP code. Didn't really know where to start. But that's another story. I should probably look harder. Anyway, I got a renewed itch now to look at the PS interpreter. :-) 1. How do you anticipate deploying this? It looks like the user is aware of which implementation he is using, and therefore knows or can find the class(es) that implement the interface(s). So it looks like your org.xml.fo org.xml.fo.helper stuff would go in some vendor-neutral project, and the implementations would simply be part of the vendor package. Does that sound right? Exactly. That's where the whole thing is slightly different to JAXP. I want to have multiple implementations at the same time and I want to control which. Either you set up the classpath yourself and instantiate the right FOProcessorFactory or you use the XML package format to load an implementation dynamically along with additional libraries (Barcode4J comes to mind) and use that. 2. One thing that I really like about your idea is that, if done properly, the implementation classes almost become self-documenting tutorials on the API for the specific implementation. If jafop exposes a general API for what is needed to process an FO document, then the innards of the implementation show how to use the API for the specific implementation. Right. :-) That one didn't occur to me. 3. There is more going on here than I anticipated. In org.xml.fo, there are four interfaces that a vendor needs to implement. I am not sure what FOPEventListener is supposed to do. Of the other three, it looks like two of them exist to handle variations in input. I *think* that these could be boiled down to just one interface, and that the input variations could be handled with overloaded methods or some other way. However, I sure could be missing something. FOPEventListener is an unfinished idea to get information on things happening inside an FO processor. Examples: Overflow warnings, Missing images, new pages etc. Nothing's implemented in this direction, yet. FOProcessor (equivalent to JAXP Transformer) represents the actual FO processor even if the implementation isn't implemented that way. Actually, I routed the implementation of the process() method through the Handler. The main idea is to establish the same structure known from JAXP. I'm aware that the FOProcessor.process() method will probably never be used except for trivial examples not involving XSLT. The FOProcessorHandler is the real work horse IMO. It's used to bind XSLT output to FO input through SAX events. The Factory interface is simply responsible to instantiate the FOProcessor(Handler) implementations. It's probably best if I just publish the sources so things become clearer. Will do that later today. 4. If you think aXSL is an appropriate home for the vendor-neutral pieces of this, that would make some sense to me. As we have previously discussed, jafop is a subset of what aXSL is supposed to eventually handle. Vendors using the app or jafop or whatever part of aXSL would be free to ignore the other parts of it, if and when they appear. The problem with aXSL I've got WRT JAFOP is that it would IMO create confusion between stuff for FO implementation developers and FO users. Another point: Sun donated JAXP to the ASF. So the ASF may not be a bad place after all, as long it's not directly within the FOP source code. JAXP, Xerces-J and Xalan-J are all in different locations. 5. I know when I see the substring FOP in the vendor-neutral part of this stuff, that it is being used in a vendor-neutral way. However, since the general term FO Processor has already been taken by a specific implementation, it may be good to find some variation, not only for political reasons, but practical as well (cuts down on confusion). Maybe something as simple as PFO, or maybe the aXSL name can help here. That's been bothering me, too. It's also the reason why I mentioned that the naming can change. :-) I'd also prefer something a little farther from FOP but nothing really good has occured to me, yet. Good ideas always welcome. Something with XSL in the name seems problematic to me because I often run into people who can't distinguish XSL, XSLT and XSL-FO. Staying near FO would help avoid any confusion. I think you have done a good thing here. Thanks. We'll see what comes out of it. Jeremias Maerki
FOP code in FOray [WAS: Preview for a general XSL-FO processing API]
Jeremias Maerki wrote: I finally downloaded the Foray code yesterday because I thought it might be fun to write that implementation already. I didn't invest a lot of time but I got confused about the mixture of Foray and FOP code. Didn't really know where to start. But that's another story. I should probably look harder. Anyway, I got a renewed itch now to look at the PS interpreter. :-) The code in the fop-maint branch is code that has not yet been peeled off into a FOray module. All of it eventually will be. The case of the app module, which will eventually contain the API that you are looking for is in an especially bad state ATM. I renamed the CLI class Fop to FOray and also moved it into the FOray apps package (it seemed especially confusing to ask users to start Foray from either a class or package with fop in its name). However, all of the other related classes still live on the fop-maint side. So the main class you are looking for is org.foray.app.FOray, but if you follow in a debugger, you will quickly be over in org.apache.fop.apps.Starter, and most of the rest of that package will look pretty similar to FOP's maintenance branch. The reason for this state is that I want to make major changes to that outer layer of the API, but it won't get done until I get a bit further along in getting the FOTree peeled off. I hope that helps. If you try to use FOray ATM, you may get errors on properties, which is also currently in an ugly state, half using the old scheme and half using the new scheme. I am not aware of any actual errors ATM, but there almost certainly are. My general advice would be to wait until I have it in a beta quality state again, but the other option is just to let me know if a bug is causing you problems. Victor Mote
Re: Preview for a general XSL-FO processing API
I've uploaded the sources (ALv2) to http://www.maerki.org/jeremias/dev/jafop/ In the meantime, I've improved a few things: - javadocs improved a bit - added support for specifying a userconfig.xml file for the FOP maintenance branch implementation (through FOProcessorFactory.setAttribute(userconfig, filename)) - minimal implementation for JFOR On 26.11.2004 23:08:50 Jeremias Maerki wrote: If there's enough interest I can put the source code for the API plus implementations on my website (or to a SF project or somewhere else). Jeremias Maerki
