Enable xsl:message output

[GoogleCodeExporter]

As for now the plugin disable the xsl:message to be printed on the console, 
maybe something clever can be found.
It was disabled because of FOP printing a lot of things on the console.

@see 
http://groups.google.com/group/docbkx-tools-users/browse_thread/thread/78d887e14
bbe4dcb

Mimil,

Original issue reported on code.google.com by MimilO...@gmail.com on 25 Mar 2011 at 7:03

[GoogleCodeExporter]

Hi Cedric, 

I am helping David with this issue. Can you point me to to the docbkx class 
that handles the suppression of xsl messages in non -X mode, or inform me of a 
possible configuration attribute that would turn off this feature, thanks.

---Thu

Original comment by thu....@gmail.com on 15 Dec 2011 at 9:56

[GoogleCodeExporter]

Hello,

it is located in AbstractTransformerMojo class in createTransformer() method.

Do you know if there is a debug mode in the xslts? maybe we can use same 
parameter else we will have to define a new one.

Regards,
Cedric,

Original comment by MimilO...@gmail.com on 16 Dec 2011 at 1:34

[GoogleCodeExporter]

There is a chunk.quietly param which suppresses the message about each file 
being printed out. The only other "noisy" message is the warning when sections, 
chapters, etc don't have an id. These are controlled by the id.warnings 
parameter. If you set both to 0, then the xsls should be fairly quiet. It looks 
like by default id.warnings is 0 but chunk.quietly is 0. 

Neither of those look to be exactly what we want. I would say just coin a new, 
Docbkx-specific setting "showXslMessages" or whatever. I think in our 
customization we would default it to show messages.

Thanks,
David

Original comment by crame...@gmail.com on 16 Dec 2011 at 9:10

[GoogleCodeExporter]

s/if you set both to 0/if you set id.warnings to 0 and chunk.quietly to 1/

Original comment by crame...@gmail.com on 16 Dec 2011 at 9:11

[GoogleCodeExporter]

Okay, so let's go for showXslMessages attribute.

Original comment by MimilO...@gmail.com on 16 Dec 2011 at 9:29

[GoogleCodeExporter]

So you also want this property to be passed to the xslt?

Original comment by MimilO...@gmail.com on 19 Dec 2011 at 5:09

[GoogleCodeExporter]

commited in r246 and r247.

the new property name is showXslMessages in maven and show.xsl.messages in xslt.

Cédric,

Original comment by MimilO...@gmail.com on 19 Dec 2011 at 6:18

• Changed state: Fixed
• Added labels: Milestone-Release2.0.14

[GoogleCodeExporter]

I don't think that's necessary. This would just be a Docbkx-level switch to 
allow the user to see the messages from the xslts. There are other switches at 
the xslt level to control what is printed out.

In our customization of Docbkx, we'll turn showXslMessages on by default. In 
fact, I think that would be a good default for Docbkx too, but I understand if 
you prefer to keep the current behavior as the default.

David

Original comment by crame...@gmail.com on 19 Dec 2011 at 6:19

[GoogleCodeExporter]

Okay, xslt parameter removed in r248.

Cedric,

Original comment by MimilO...@gmail.com on 19 Dec 2011 at 6:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,

sorry for the long delay reply, with the holidays I forgot to reply to you.

it sounds the right way that *Mojo.java files do no inherit from 
AsbtractTransformerMojo.java as it is supposed to be the opposite, concrete 
classes inherit from the abstract one. So you should see the method.

I also added a setter if you have to modify it using java code (r249) into your 
custom mojo (it is defined the same way as the getter).

PS: I am uploading a new snapshot release 

Original comment by MimilO...@gmail.com on 9 Jan 2012 at 11:00

[GoogleCodeExporter]

Cedric,

Sorry for all the questions, but I think I have a better understanding of how 
the DI is working in respect with plugins.stg in docbkx-builder-maven-plugin. 
In our project we have an abstract class: PDFMojo which extends AbstractFoMojo. 
 We then generate a concrete class: DocbkxPdfMojo which extends from our 
abstract PDFMojo class.  

I assume that the DI reads from the plugins.stg file and injects all of its 
contents to the concrete class DocbkxPdfMojo henceforth showXslMessages is 
always set to false.  I just want to confirm that there is no way to customize 
this for our needs so that showXslMessages to true in the concrete class.

Thanks ahead of time.

Original comment by thu....@gmail.com on 9 Jan 2012 at 11:17