[
https://issues.apache.org/jira/browse/CAMEL-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178748#comment-13178748
]
Babak Vahdat commented on CAMEL-3774:
-------------------------------------
O.K. now I was also able to *reproduce* the issue on my box and therefore could
find a workaround for solving the problem.
If you go to [1] on your workspace and do a
{code}
mvn clean install -Dtest=foo
{code}
The PDF generation fails as described by this ticket description of Hadrian,
but if you change to [2] and do the same, then PDF will get generated
successfully (as I also attached once to this ticket while ago). Please note
that the PDF generation will be done only if the fastinstall profile is not
active so that I did above -Dtest=foo as there'e no test called "foo" I could
verify the behaviour much faster.
But what this exactly means? We do *exactly the same* at *two different*
project directory levels but the behaviour is different! One possible
explanation is [3], that's the DOM implemenataion used by the JDK-XSLT seems to
be *not thread-safe*. When you run maven at the level of [2] you have so to say
a *virgin* JDK launching up, but running maven under [1] folder it will *take a
really long way* until the build of camel-manual maven module is reached and
*exactly at this point* the inconsistency (under sun-jdk) by the class
{code}
com.sun.org.apache.xerces.internal.dom.AttrImpl
{code}
has already happened!
I've already attached the patch CAMEL-3774.patch to this ticket which resolved
the issue on my box even if I run maven at the level of the folder [1]. The
solution is pretty simply the HtmlToPdfMojo now supports *an optional*
transformerFactoryClassName field which we set to
org.apache.xalan.xsltc.trax.TransformerFactoryImpl not having this
thread-safety issue.
Please note that the prerequisite for a proper PDF generation is an available
installation of *princexml* on the PATH. On my iMac I installed it under the
PATH
{code}
/Users/bvahdat/dev/prince
{code}
And before calling maven I did
{code}
PATH=$PATH:/Users/bvahdat/dev/prince/bin
{code}
So that princexml can be successfully kicked off by HtmlToPdfMojo (plexus-utils
API is used there).
How further:
As Christian intends to provide the last 2.7.5 release (see [5]) I propose to
first apply this patch to the 2.7.x branch and if it indeed did the trick we
can still apply it afterwards to the 2.8.x and the trunk.
@Christian
Please let me know what you think about this and if you've got any questions.
Thanks!
BTW yesterday I did a full
{code}
mvn clean install
{code}
with *all* tests passing on the trunk with a proper PDF & HTML inside the
generated zip & tarball under the /doc/manual folder :-)
And just noticed that the steps regarding the princexml installation & setup is
not mentioned in [6] at all which we may also want to add as well.
[1] https://svn.apache.org/repos/asf/camel/trunk/
[2] https://svn.apache.org/repos/asf/camel/trunk/tooling/camel-manual/
[3] http://osdir.com/ml/text.xml.xforms.chiba.devel/2005-03/msg00068.html
[4] http://www.princexml.com/
[5]
http://camel.465427.n5.nabble.com/DISCUSS-Dropping-support-for-Camel-2-7-x-tp5112509p5113252.html
[6] http://camel.apache.org/release-guide.html
> camel-manual generation fails during release process
> ----------------------------------------------------
>
> Key: CAMEL-3774
> URL: https://issues.apache.org/jira/browse/CAMEL-3774
> Project: Camel
> Issue Type: Task
> Affects Versions: 2.6.0
> Reporter: Hadrian Zbarcea
> Assignee: Hadrian Zbarcea
> Fix For: Future
>
> Attachments: CAMEL-3774.patch, camel-manual-2.9-SNAPSHOT.pdf
>
>
> It works during a regular mvn install, but it fails during release:prepare.
> The bug is somewhere in the maven-html-to-pdf plugin. I hope a mock release
> using mvn -X will reveal the problem, but would take a frustrating amount of
> time. For now the available info is the output:
> {code}
> [INFO] [INFO] [html-to-pdf:compile {execution: default}]
> [INFO] [INFO] Downloading: http://camel.apache.org/book-in-one-page.html
> [INFO] ERROR: 'NOT_FOUND_ERR: An attempt is made to reference a node in a
> context where it does not exist.'
> [INFO] [ERROR] Download or validation of
> 'http://camel.apache.org/book-in-one-page.html' failed:
> org.apache.camel.CamelException: Failed to convert the HTML to tidy Markup
> [INFO] [INFO] Stored dummy file:
> /w1/apache/release/camel270/tooling/camel-manual/target/site/manual/camel-manual-2.7.0.html
> since download of http://camel.apache.org/book-in-one-page.html failed.
> {code}
> The error points to a DOM related issue, but since the downloaded manual gets
> overwritten with the dummy file, I have no idea if the download got
> interrupted, or in what way the source gets corrupted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
