Saxon

Legacy ID: #5275804 Legacy Poster: Tobias Vogt (tobias_vogt_1)

After finally locating the search function for the forum, I've found one entry (https://sourceforge.net/forum/message.php?msg_id=4079050) which could be related, as it also mentions a problem with the @force. The reason I use @force="true" is because I need to re-transform, even if the primary input document has not changed, since secondary documents may have. There may be other ways in ant to detect this, but @force is the most convenient, if build time is not really an issue.

Legacy ID: #5275936 Legacy Poster: Michael Kay (mhkay)

Thanks for reporting this. I'll take a look at it, though if it turns out to be a problem in Ant rather than in Saxon (e.g. if Ant is assuming things about JAXP implementations that are not guaranteed by the JAXP spec) then I won't necessarily be able to do anything about it.

Legacy ID: #5394428 Legacy Poster: Michael Kay (mhkay)

Sorry about the long delay in dealing with this. I've been hoping to get a proper build and debugging environment established for the Ant source code, but it's an incredibly complicated project with lots of dependencies (as one might imagine), and I decided in the end to give up on that route. I managed to establish that there are two problems here. (a) the saxon-xslt task is processing each of the files twice. This seems to be a bug present in code that was copied into the saxon-xslt task from the generic xslt task. It is first processing all the selected files, then all the selected directories, and the scan of selected directories processes the contained files a second time. I'm not very familiar with the way this stuff works in Ant, so I may ask some questions on an Ant forum, but I will try to fix it. (b) when Ant runs multiple transformations using the same stylesheet, it reuses the JAXP Transformer object rather than the JAXP Templates object. This isn't the recommended way of working with Saxon, though it works, but it's very common in the Apache/Xalan world. It's because the Transformer is reused that you're getting the message about writing twice to the same destination: the list of destinations that have been written to is held within the Transformer, and not cleared at the end of a transformation. I've already changed the saxon-xslt task to reuse the Templates rather than the Transformer, which will solve this problem for saxon-xslt, though not for the generic xslt task. However, I probably should fix the Transformer so it clears this data after finishing a transformation. Michael Kay

Legacy ID: #5394609 Legacy Poster: Tobias Vogt (tobias_vogt_1)

In my initial report, I wrote: "The same problem will occur, when using Saxon through the standard ant xslt task, but not when using the xslt task with the default processor.". I just retested with the standard xslt task and default processor and it is not really true, that the problem does not occur: Here too, both files are transformed twice, which does not cause an error, but obviously does not make sense either. I had not noticed this last time. I also checked whether I might be using the xslt task in the wrong way, but my example is almost identical with one given on the ant online manual (http://ant.apache.org/manual/CoreTasks/style.html >Using a mapper): <xslt basedir="in" destdir="out" style="style/apache.xsl"> <mapper type="glob" from=".xml.en" to=".html.en"/> </xslt> So there really is a sort of bug in the xslt task. Thanks for your investigation and improvements. Tobias

Legacy ID: #5394840 Legacy Poster: Michael Kay (mhkay)

A bit of further information. You can prevent the double processing by setting scanIncludedDirectories="false" on the xslt or saxon-xslt task. It just remains to discover why you would want to set it to "true", and why "true" is the default.

Legacy ID: #5399878 Legacy Poster: Tobias Vogt (tobias_vogt_1)

You are right - using scanIncludedDirectories="false" is a good workaround for me. Thanks for the tip! Regarding why one would want to set it to true: I don't know, whether you saw the hint on the Apache doc page "Note: Unlike other similar tasks, this task treats directories that have been matched by the include/exclude patterns...". So there seems to be some kind of intended special behavior for the xslt task. Unfortunately, I'm not deep enough into Ant to really make sense of that note.

Legacy ID: #5399909 Legacy Poster: Michael Kay (mhkay)

Stefan Bodewig from Apache tells me that the scanIncludedDirectories property was introduced to enable this undesirable behaviour of the <style> task to be suppressed, but they left the default value as true because they were worried about backwards compatibility. I haven't quite worked out what the implications are, but it would seem right to change the default to false for the saxon-xslt task. Michael Kay