Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Finn Bock
Why is it more efficient (I know it is, given your
metrics, but want to know why)--aren't you just moving
the values already stored in the PropertyList into
separate fields in the FO objects?  Yes, you're
releasing the PropertyList's memory, but the elements
that the PropertyList previously stored are now stored
in the FObj. 
So if PropertyList can be thought of as a C-like
struct holding the values of its FObj's properties,
what you're doing appears to be just taking that
struct's member variables and moving them to the FObj.

But, obviously, given the performance/memory boost
you're noting, PropertyList *can't* be regarded as a
C-like struct.  Why?  Could PropertyList be made more
efficient instead of this change--make it more like a
C-like struct?
[Peter]
It's a mixed bag, by the look of it.  From the patch, applying to FOText:
+// The value of properties relevant for character.
+private CommonFont commonFont;
+private CommonHyphenation commonHyphenation;
+private ColorType color;
+private Property letterSpacing;
+private SpaceProperty lineHeight;
+private int whiteSpaceCollapse;
+private int textTransform;
+private Property wordSpacing;
+private int wrapOption;
+
+// End of property values
Note the combination of simple fields for whiteSpaceCollapse and more
complex structures like CommonFont.
I really like the combination of CommonXXX structures and simple fields, 
since it litterally matches the spec. Except that the spec doesn't have 
a FOText element so it is a bad example for me to use. The fields in 
FOText was taken from TextInfo and I suspect that eventually more fields 
will be needed in FOText.

In the rest of the elements, the set of fields matches the spec. The 
only exception is a bug where the some of the inline LayoutManagers uses 
vertical-align which is a shorthand. The layoutmanagers should instead 
use the properties that the shorthand sets: alignment-baseline, 
alignment-adjust, baseline-shift and dominant-baseline. But since only 
one of these properties has been implemented yet, I choose to keep the 
use of vertical-align for now.

Alt-design just uses a sparse array, constructed at END_ELEMENT.  Space
savings are progressively realized as the depth of the FO Tree reduces.
 Maximum consumption occurs at the points of greatest depth of the
tree, minima at the end of each page-sequence.
IIRC your sparse array does not just contain the relevant properties for 
an element (those listed in the spec under each fo:element), but the 
joined set of all properties relevant for all the allowed children. If 
this is correct, the sparse arrays stores more properties and uses more 
memory than my proposal does.

Finn has gone a step further, and collapsed the property structures into
local variables, which is good for both memory consumption and speed, at
the cost of some more code.  IIUC.
Correct. In addition I also get a certain level of typesafeness for the 
properties.

regards,
finn


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

2004-10-15 Thread Jeremias Maerki
I don't know what goes wrong here, but please try putting the latest
Xerces and Xalan releases in the jre/lib/endorsed directory of your JDK.
I temporarily took out my JARs in the endorsed directory to see if
anything changed but it didn't. Are you on JDK 1.4.2_something? I'm on
1.4.2_05.

On 12.10.2004 09:19:38 Finn Bock wrote:
 I get an error:
 
 junit:
   [echo] Running basic functionality tests for fop-transcoder.jar
  [junit] Testsuite: org.apache.fop.BasicTranscoderTestSuite
  [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3,968 sec
 
  [junit] - Standard Output ---
  [junit] drawImage x=7 y=277 width=97 height=14 
 [EMAIL PROTECTED]: type = 2 DirectColorModel: rmask=ff 
 gmask=ff00 bmask=ff amask=ff00 IntegerInterleavedRaster: width = 97 
 height = 14 #Bands = 4 xOff = 0 yOff = 0 dataOffset[0] 0
  [junit] -  ---
   [echo] Running basic functionality tests for 
 fop-transcoder-allinone.jar
  [junit] Testsuite: org.apache.fop.BasicTranscoderTestSuite
  [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,281 sec
 
  [junit] - Standard Error -
  [junit] java.io.IOException: SAX2 driver class 
 org.apache.xerces.parsers.SAXParser not found
  [junit]  at 
 org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)



Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/apps FOUserAgent.java

2004-10-15 Thread Jeremias Maerki
Sorry for the delay.

On 12.10.2004 01:20:54 Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  Glen,
  
  I don't
  particularly like selecting renderers by integer
  constant. 
 
 FOP has been using integers for six years now, and as
 I explained earlier [1], MIME types don't make a very
 good primary key for renderers, because not all
 renderers have a MIME type, also multiple renderers
 can share the same MIME type (e.g. our PDF renderer
 and Finn's version of it.).  In some cases, we would
 may indeed need a RENDER_PDF_V14 and an
 RENDER_PDF_V15, for example. 

I would disagree with that. There are ways to do all that pretty cleanly.
The point is that with your approach you always (!) have to work in Java
code to use a non-standard renderer. It can't be plugged in from the
command-line for example.

 Again, integer constants also work well in arrays,
 they are ultra-fast, and, as a bonus, new
 Fop(RENDER_PFD) is a ultra-quick-to-catch
 compile-time error, while new FOP(application/pfd)
 would turn into a pesky run-time error (and even a ML
 question).  The integer constants are also much easier
 to remember than MIME types:  RENDER_ followed by the
 desired render type. 

Performance is really unimportant when we're talking about choosing the
renderer. The compile-time checking argument is valid, however.

 [1]
 http://marc.theaimsgroup.com/?l=fop-devm=109261374110951w=2
 
  I like
  pluggability. 
 
 We sufficiently have that for our next release, where
 I define sufficiently as as much as we have already
 in 0.20.5, and basically what AH/RX offers.  We have
 already learned that adding too many hooks,
 interfaces, visitor patterns, *before* the
 layout/renderer work is done, results in FOP never
 getting finished because the code becomes too hard to
 work through.  So let's get the code working first
 (moving the renderers over, whitespace handling, PDF
 bookmarks, layout), *then* put it into Mandarin with
 the advanced API many desire.  

As you like. But this will stay on my personal todo list.

 I share your impatience with the next release not
 coming out yet, but we have to keep the code simple to
 get more people to look at and help in the code.

I agree, but IMHO it's confusing that we're choosing standard renderers
in one place (Fop.java) but provide a possibility to set non-standard
renderer in another (FOUserAgent.java).

  I'd prefer to register all our
  renderers in a central
  registry. Integrators could plug in their renderers
  using the service
  interface just as the FOP extension can. 
 
 That's beautiful post-0.30/1.0 talk that should be
 added to our roadmap.  But, in the meantime, we
 already have a perfectly satisfactory
 FOUserAgent.setRendererOverride() that will satisfy
 the users that currently have renderer overrides.  I
 would prefer a minimal API with as much black-boxed as
 possible to allow future implementors as much
 architectural freedom as possible.
 
 Besides, what you prefer now is not what the team
 preferred six months ago, or a year ago, or 18 months
 ago, etc., etc.  Our API/internal architecture desires
 keep changing. 

Are they? Is that how you justify ignoring API discussions held earlier?

  You could
  even override
  renderers (for application/postscript for example)
 
 We already have that with
 setRendererOverride(Renderer).  You can't use MIME
 type for reasons given above.

I can't override a Renderer without changing Java code.

  if you have a
  renderer with some custom extensions. IMO
  FOUserAgent is already
  overloaded with too many different things. 
 
 That is because we tend to, whenever any user might
 want something, give him/her an API method for it. 
 The only way we can satisfy these many needs without
 forever locking the FOP architecture (each of these
 switches internally modifying the behavior of one
 internal class or another) is to add the method to
 FOUserAgent, and have internal classes read it, rather
 than the other way around.  Furthermore, we have one
 class--FOUserAgent--for these parameters to make the
 embedded/servlet API easier for non-advanced users. 
 (BTW, FOUserAgent should be reduced somewhat anyway,
 when we create fox:metadata or whatever.)

Means keep Fop.java as lean as possible but no problem with FOUserAgent
getting bloated. I don't get it.

  I think
  that the overrides
  don't belong there, or rather they are probably
  unnecessary given a
  better renderer selection mechanism.
  
 
 Oh, I think they do, it is sufficient for our next
 release.  Nothing is easier, nothing is simpler for
 embedded/servlet users.  Take a look at the 1.0
 embedded examples.

My desires for the API don't complicate things for the embedded examples.

  What triggered the creation of the RendererFactory
  was not IoC but the
  other Avalon concept: Separation of concerns. I
  think that handling
  renderer and FOEventHandler creation in a separate
  class rather than in
  the quite crowded FOTreeBuilder and 

Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Clay Leeds
On Oct 15, 2004, at 12:05 AM, Finn Bock wrote:
snip
In the rest of the elements, the set of fields matches the spec. The 
only exception is a bug where the some of the inline LayoutManagers 
uses vertical-align which is a shorthand. The layoutmanagers should 
instead use the properties that the shorthand sets: 
alignment-baseline, alignment-adjust, baseline-shift and 
dominant-baseline. But since only one of these properties has been 
implemented yet, I choose to keep the use of vertical-align for now.
When I look at the FOP Compliance page, I see a couple of items which 
are implemented (I assume this page is in reference to the 
0_20_2-maintain CVS branch--I am I correct in this assumption?).

alignment-adjust - no
alignment-baseline - no
baseline-shift - partial (see * below)
* Only values super and sub have been implemented.
display-align - yes - (partial extended conformance--see ** below)
** Implemented only for table-cell and block-container.
** For table-cell, the height attribute must be set for the parent 
table-row; setting the height of the table or the table-cell results in 
vertical centering having no effect.

dominant-baseline - no
relative-align - yes - no
Which of the alignment-* property is the one you're referring to that 
has been implemented?

Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Chris Bowditch
Clay Leeds wrote:
snip/
When I look at the FOP Compliance page, I see a couple of items which 
are implemented (I assume this page is in reference to the 
0_20_2-maintain CVS branch--I am I correct in this assumption?).
Hi Clay - yes compliance page does refer to 0.20.5 functionality.
snip/
Chris


Re: DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread Luca Furini

Simon Pepping wrote:

 1. InlineStackingLM implements InlineLM.  LineLM extends
 InlineStackingLM and thus implements InlineLM. IMHO it should
 not. Implementing InlineLM should be equivalent to
 generatesInlineAreas returning true.

You are right, it's quite strange, but the LineLM still uses a few methods
inherited from InlineStackingLM. This was not due to the new algorithm, it
was already in the old code; I'm going to see if they still do something
useful ...

 2. TextLM now extends LeafNodeLM instead of AbstractLM. What is the
 gain?  I see no related changes in TextLM.

There isn't at the moment any practical gain, I just thought that, as a
text node has no children, a TextLM is a (special case of) LeafNodeLM.

 3. In LineLM:
 // this constant is used to create elements when text-align is center:
 // every TextLM descendant of LineLM must use the same value,
 // otherwise the line breaking algorithm does not find the right
 // break point
 public static final int DEFAULT_SPACE_WIDTH = 3336;
 private static final int INFINITE_RATIO = 1000;

 If these are static final, they might be better placed in
 InlineLM. Alternatively, they might be attributes of the LineLM
 object, which allows changing them per paragraph, e.g. depending on
 the font. But then the problem arises how to propagate them to the
 descendant LMs.

I decided to change and use a constant because the important thing is to
have the same value used by every LM, but this isn't the perfect solution;
if we try to center a short object (a single word, for example) in a long
line, it is likely that the algorithm fails because there isn't enough
stretchability in the line.
Maybe it's better to have the LineLM compute a value depending on the line
lenght and the maximum adjustment ratio; the child LM should ask the
LineLM for this value.

 4. The textheight of the large font is rather large. The property
 lineheight is not followed (reproduce existing behaviour).

 5. LineLayoutManager:675: line is always 3, so that firstElementIndex
 = 1 for the first line, and the first box is skipped in the line
 height calculation.

The second version of the patch, which I'm going to attach to the Bugzilla
issue, fixes these errors.

It also implement the vertical-align property: now the values of top,
bottom, middle and baseline should be supported.
I made a few tests with fo:inline, fo:character and fo:external-graphic,
and it seems to work.

IMPORTANT: I had to revert Finn Bock's changes to the PDFRenderer (dated
2004/09/22 13:22:16), otherwise leaders with svg use-content produce
errors in the pdf output.
There isn't any run-time error, but when I try to open the pdf file, I get
these warnings:
 - There was an error processing a page. Wrong operand type.
 - Illegal operation 'q' inside a text object.
 - Wrong operand type.
and the page with the svg leaders is left empty.
I think it could be something involving the saveGraphicsState() method.

Still to be done:
  - remove unused methods and variables
  - simplify InlineStackingLM methods as suggested by Simon
I'll try and fix these points as soon as possible.

Regards
Luca




DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:22 ---
I'm going to attach a revised version of the improvement patch:

- it fixes the line-height calculation errors
- better handling of preserved linefeed

I'm going to attach some test files too.

Regards
Luca


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:22 ---
Created an attachment (id=13099)
revised patch


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:24 ---
Created an attachment (id=13100)
leaders with pattern = rule, dots and use-content with svg graphics


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:24 ---
Created an attachment (id=13101)
vertical alignment (top, bottom, middle, baseline) of inlines


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:25 ---
Created an attachment (id=13102)
vertical alignment of images


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:26 ---
Created an attachment (id=13103)
file 15px.gif used in the test fo file


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:26 ---
Created an attachment (id=13104)
file 20px.gif used in the test fo file


DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31206.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31206

[PATCH] Improvements over the new line breaking algorithm





--- Additional Comments From [EMAIL PROTECTED]  2004-10-15 16:26 ---
Created an attachment (id=13105)
file 30px.gif used in the test fo file


Re: DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread Finn Bock
[Luca]
IMPORTANT: I had to revert Finn Bock's changes to the PDFRenderer (dated
2004/09/22 13:22:16), otherwise leaders with svg use-content produce
errors in the pdf output.
There isn't any run-time error, but when I try to open the pdf file, I get
these warnings:
 - There was an error processing a page. Wrong operand type.
 - Illegal operation 'q' inside a text object.
 - Wrong operand type.
and the page with the svg leaders is left empty.
I think it could be something involving the saveGraphicsState() method.
I've just now fixed this issue so that your patch work with the PDFRenderer.
regards,
finn


Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Finn Bock
[Clay]
Which of the alignment-* property is the one you're referring to that 
has been implemented?
I was just looking at them from the point of view of the property 
subsystem, where only baseline-shift has been implemented. I didn't 
mean to imply that it actually work all the way through layout.

regards,
finn


Re: [Fwd: Re: Performance improvement in property consumption.]

2004-10-15 Thread Clay Leeds
On Oct 15, 2004, at 1:02 PM, Finn Bock wrote:
[Clay]
Which of the alignment-* property is the one you're referring to that 
has been implemented?
I was just looking at them from the point of view of the property 
subsystem, where only baseline-shift has been implemented. I didn't 
mean to imply that it actually work all the way through layout.

regards,
finn
That's fine... I saw that, and wondered which. Thanks for letting me 
know!

Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc


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

2004-10-15 Thread Jeremias Maerki
Hi Gumpers,

we're currently facing a somewhat strange failure of FOP in Gump. I
don't have that failure locally. One of the other committers as a
different error but that's probably related to some weird Xerces problem.

It seems like the JUnit task doesn't pick up the test classes that were
compiled beforehand.

Does anyone have an idea what could be wrong here? Would maybe forking
the junit task help? Thanks for any ideas.

On 13.10.2004 20:53:34 Sam Ruby wrote:
 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- Failed with reason build failed
  -DEBUG- Extracted 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: 49 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/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
  org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/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/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-13102004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-b
at
 ik/batik-13102004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-13102004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-13102004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-13102004.jar:/
us
 r/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-13102004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-13102004.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-13102004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-13102004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar
 

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

2004-10-15 Thread Jeremias Maerki
Excellent. Thanks a lot!

On 15.10.2004 10:53:30 Stefan Bodewig wrote:
 On Fri, 15 Oct 2004, Jeremias Maerki [EMAIL PROTECTED]
 wrote:
 
  It seems like the JUnit task doesn't pick up the test classes that
  were compiled beforehand.
 
 Yes, because you didn't run unit tests before, it hasn't been part of
 the Gump descriptor.  I've already fixed it.
 
 Stefan


Jeremias Maerki