Re: Preview for a general XSL-FO processing API

2004-11-27 Thread Jeremias Maerki
I'm extremely sorry about not making it clearer that I don't intend to
launch a new API discussion for FOP or that I don't want to force anyone
to do anything. This JAFOP thing is just a personal project I thought
others might be interested in.

Thank you for your suggestions. However, I don't think that EXSLFO would
be the right place as it is focused to standardize on the XSL-FO
language as such, not necessarily on Java API bindings. It could, on the
other side, be launched as a JSR if there is sufficient interest in the
community. It also occured to me that the API might be strong enough to
accomodate other dialects like SVG. But these are just random synaptic
shots.

On 27.11.2004 06:36:47 Glen Mazza wrote:
 As long as a FOP user is not *required* to use it, (i.e., they can 
 ignore JAFOP entirely and still call FOP's native JAXP-based API as in 
 our embed examples), and as long as JAFOP is implemented using our 
 current API, then I don't think I would have much problem with it.  I 
 don't want us to lose our present JAXP capabilities though--JAXP is a 
 useful skill for our users to become proficient in, and something I 
 would like us to continue promoting.
 
 But your idea -- an interface that allows for run-time swapping of FO 
 processors (like JAXP allows for Xalan and Saxon to be switched) is not 
 bad at all.  I wish the folks at AH and RX would create such an 
 interface that we could just implement.  Two thoughts come to mind:  (1) 
 perhaps we should try to reactivate that EXSLFO group and move this 
 topic to them, and (2) you may wish to take a look at the JAXP 
 specification, if you haven't recently, and see if there are any 
 issues/ideas/things you perhaps forgot to take into account, etc., with 
 JAFOP.  That spec should show you what needs to be done for a common 
 interface to be accepted, including things you may have missed.



Jeremias Maerki



[GUMP@brutus]: Project xml-fop (in module xml-fop) failed

2004-11-27 Thread Sam Ruby
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.
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-27112004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-27112004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-27112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-27112004.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-27112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-27112004.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-27112004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-27112004.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

2004-11-27 Thread Victor Mote
Jeremias Maerki wrote:

 I've talked about it before, so in case anybody is interested 
 I've uploaded the Javadocs [1] for a general XSL-FO 
 processing API I've been working on during the last few 
 weeks. It's basically my API proposal that is (or rather was) 
 on the Wiki. I've called it JAFOP (Java API for XSL-FO 
 processing) for now. But naming can change... The 
 implementations for FOP maintenance branch and FOP HEAD 
 already work for simple use cases. No fancy stuff, yet (no 
 events, no userconfig.xml...). 

...

 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).
 
 I believe this common API could be interesting in the 
 following months when FOP HEAD advances. It can be used to 
 easily switch implementations or during development/testing. 
 And I've got a few additional ideas. As time allows...
 
 It might also be interesting to have implementations for 
 Foray, Defoe, XEP and maybe even ol' JFOR. I hope the design 
 is flexible enough to accomodate all Java implementations.

Hi Jeremias:

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:

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?

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.

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.

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.

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.

I think you have done a good thing here.

Victor Mote



Re: Preview for a general XSL-FO processing API

2004-11-27 Thread The Web Maestro
This all sounds great to me. I like the sound of it very much. As for  
the javadocs stuff, there's ongoing discussion on the Forrest DEV  
list[1] which discusses 'RAW' files (the category in which Javadocs  
fall). Since that isn't ready yet, perhaps we'll have to go for some  
other javadocs implementation?

As for a 'location' for JAFOP, how about the Objects for Formatting  
Objects (OFFO[2])?

Web Maestro Clay
[1]
http://mail-archives.apache.org/eyebrowse/ReadMsg? 
[EMAIL PROTECTED]msgNo=15979

[2]
http://offo.sourceforge.net/
On Nov 27, 2004, at 12:06 AM, Jeremias Maerki wrote:
I'm extremely sorry about not making it clearer that I don't intend to
launch a new API discussion for FOP or that I don't want to force  
anyone
to do anything. This JAFOP thing is just a personal project I thought
others might be interested in.

Thank you for your suggestions. However, I don't think that EXSLFO  
would
be the right place as it is focused to standardize on the XSL-FO
language as such, not necessarily on Java API bindings. It could, on  
the
other side, be launched as a JSR if there is sufficient interest in the
community. It also occured to me that the API might be strong enough to
accomodate other dialects like SVG. But these are just random synaptic
shots.

On 27.11.2004 06:36:47 Glen Mazza wrote:
As long as a FOP user is not *required* to use it, (i.e., they can
ignore JAFOP entirely and still call FOP's native JAXP-based API as in
our embed examples), and as long as JAFOP is implemented using our
current API, then I don't think I would have much problem with it.  I
don't want us to lose our present JAXP capabilities though--JAXP is a
useful skill for our users to become proficient in, and something I
would like us to continue promoting.
But your idea -- an interface that allows for run-time swapping of FO
processors (like JAXP allows for Xalan and Saxon to be switched) is  
not
bad at all.  I wish the folks at AH and RX would create such an
interface that we could just implement.  Two thoughts come to mind:   
(1)
perhaps we should try to reactivate that EXSLFO group and move this
topic to them, and (2) you may wish to take a look at the JAXP
specification, if you haven't recently, and see if there are any
issues/ideas/things you perhaps forgot to take into account, etc.,  
with
JAFOP.  That spec should show you what needs to be done for a common
interface to be accepted, including things you may have missed.

Jeremias Maerki

Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet