[jira] [Commented] (CAMEL-3774) camel-manual generation fails during release process

["Babak Vahdat (Commented) (JIRA)" <ji...@apache.org>]

    [ 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