Camel
  1. Camel
  2. CAMEL-3774

camel-manual generation fails during release process

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.6.0
    • Fix Version/s: 2.7.5, 2.8.4, 2.9.1, 2.10.0
    • Component/s: None
    • Labels:
      None

      Description

      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:

      [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.
      

      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.

      1. camel-manual-2.9-SNAPSHOT.pdf
        4.09 MB
        Babak Vahdat
      2. CAMEL-3774.patch
        5 kB
        Babak Vahdat

        Issue Links

          Activity

          Hide
          Claus Ibsen added a comment -

          This issue doesnt affect Camel end users so changing to task type

          Show
          Claus Ibsen added a comment - This issue doesnt affect Camel end users so changing to task type
          Hide
          Babak Vahdat added a comment -

          Had a quick chance to look at this after the 2.8.3 release today. Be warned, I'm not a Apache Maven expert, so maybe I'm completely wrong

          Looking at [1] it says:

           private String downloadContent() throws MalformedURLException, MojoExecutionException {
                  String contentTag = "<div class=\"" + contentDivClass + "\"";
          
                  getLog().info("Downloading: " + page);
                  URL url = new URL(page);        
                  
                  try {
                      TidyMarkupDataFormat dataFormat = new TidyMarkupDataFormat();
                      dataFormat.setMethod("html");
                      Node doc = dataFormat.asNodeTidyMarkup(new BufferedInputStream(url.openStream()));
                      XPath xpath = XPathFactory.newInstance().newXPath();
                      Node nd = (Node)xpath.evaluate("//div[@class='" + contentDivClass + "']", doc, XPathConstants.NODE);
                      if (nd != null) {
                          return  new XmlConverter().toString(nd, null);
                      }
                  } catch (Throwable e) {
                      if (errorOnDownloadFailure) {
                          throw new MojoExecutionException("Download or validation of '" + page + "' failed: " + e);
                      } else {
                          getLog().error("Download or validation of '" + page + "' failed: " + e);
                          return null;
                      }
                  }        
                  throw new MojoExecutionException("The '" + page + "' page did not have a " + contentTag + " element.");
              }
          

          On the other hand the default value of contentDivClass by this Mojo is:

          /**
            * The first div with who's class matches the contentDivClass will be
            * assumed to be the content section of the HTML and is what will be used as
            * the content in the PDF.
            *
            * @parameter default-value="wiki-content"
            */
            private String contentDivClass = "wiki-content";
          

          But looking at [2] the real value of the div-class element is:

          <DIV class="wiki-content maincontent">
          

          So that the exception message of the TidyMarkupDataFormat doesn't surprise me too much:

          [INFO] ERROR:  'NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.'
          

          Other than that the method storeDummyFile() of [1] is:

          private void storeDummyFile() throws FileNotFoundException {
                  PrintWriter out = new PrintWriter(new BufferedOutputStream(new FileOutputStream(getHTMLFileName())));
                  out.println("<html>");
                  out.println("<body>Download of " + page + " failed</body>");
                  out.close();
                  getLog().info("Stored dummy file: " + getHTMLFileName() + " since download of " + page + " failed.");
              }
          

          which doesn't generate a valid HTML (the closing html tag is missing). IMHO we should generate something like:

          <html>
           <body>
            <a href="http://camel.apache.org/book-in-one-page.html">Generation of the offline PDF version of the manual failed, however you could try the online HTML version here.</a>
           </body>
          </html>
          

          So that in the case something goes wrong whatsoever we would still have a proper HTML pointing to the online version of the manual.

          I would love to provide a patch for this issue (I know, you love contributions ), however I'm afraid I will not be able to verify that as I'm not a committer so that release:prepare would fail before ahead (I assume). So maybe some Rider (Hadrian?) could locally check/verify the patch before applying it into the trunk...

          Any thoughts?

          [1] https://svn.apache.org/repos/asf/camel/trunk/tooling/maven/maven-html-to-pdf/src/main/java/org/apache/camel/maven/HtmlToPdfMojo.java
          [2] http://camel.apache.org/book-in-one-page.html

          Show
          Babak Vahdat added a comment - Had a quick chance to look at this after the 2.8.3 release today. Be warned, I'm not a Apache Maven expert, so maybe I'm completely wrong Looking at [1] it says: private String downloadContent() throws MalformedURLException, MojoExecutionException { String contentTag = "<div class=\" " + contentDivClass + " \""; getLog().info( "Downloading: " + page); URL url = new URL(page); try { TidyMarkupDataFormat dataFormat = new TidyMarkupDataFormat(); dataFormat.setMethod( "html" ); Node doc = dataFormat.asNodeTidyMarkup( new BufferedInputStream(url.openStream())); XPath xpath = XPathFactory.newInstance().newXPath(); Node nd = (Node)xpath.evaluate( " //div[@class='" + contentDivClass + "']" , doc, XPathConstants.NODE); if (nd != null ) { return new XmlConverter().toString(nd, null ); } } catch (Throwable e) { if (errorOnDownloadFailure) { throw new MojoExecutionException( "Download or validation of '" + page + "' failed: " + e); } else { getLog().error( "Download or validation of '" + page + "' failed: " + e); return null ; } } throw new MojoExecutionException( "The '" + page + "' page did not have a " + contentTag + " element." ); } On the other hand the default value of contentDivClass by this Mojo is: /** * The first div with who's class matches the contentDivClass will be * assumed to be the content section of the HTML and is what will be used as * the content in the PDF. * * @parameter default -value= "wiki-content" */ private String contentDivClass = "wiki-content" ; But looking at [2] the real value of the div-class element is: <DIV class= "wiki-content maincontent" > So that the exception message of the TidyMarkupDataFormat doesn't surprise me too much: [INFO] ERROR: 'NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.' Other than that the method storeDummyFile() of [1] is: private void storeDummyFile() throws FileNotFoundException { PrintWriter out = new PrintWriter( new BufferedOutputStream( new FileOutputStream(getHTMLFileName()))); out.println( "<html>" ); out.println( "<body>Download of " + page + " failed</body>" ); out.close(); getLog().info( "Stored dummy file: " + getHTMLFileName() + " since download of " + page + " failed." ); } which doesn't generate a valid HTML (the closing html tag is missing). IMHO we should generate something like: <html> <body> <a href= "http: //camel.apache.org/book-in-one-page.html" >Generation of the offline PDF version of the manual failed, however you could try the online HTML version here.</a> </body> </html> So that in the case something goes wrong whatsoever we would still have a proper HTML pointing to the online version of the manual. I would love to provide a patch for this issue (I know, you love contributions ), however I'm afraid I will not be able to verify that as I'm not a committer so that release:prepare would fail before ahead (I assume). So maybe some Rider (Hadrian?) could locally check/verify the patch before applying it into the trunk... Any thoughts? [1] https://svn.apache.org/repos/asf/camel/trunk/tooling/maven/maven-html-to-pdf/src/main/java/org/apache/camel/maven/HtmlToPdfMojo.java [2] http://camel.apache.org/book-in-one-page.html
          Hide
          Hadrian Zbarcea added a comment -

          Your findings are consistent with mine. The part I didn't figure out is why the manual is generated properly via mvn install but not during release:prepare. I stopped looking at it a while back, but I owe it to your efforts to look into it again.

          I'll be back with details. Thanks.

          Show
          Hadrian Zbarcea added a comment - Your findings are consistent with mine. The part I didn't figure out is why the manual is generated properly via mvn install but not during release:prepare. I stopped looking at it a while back, but I owe it to your efforts to look into it again. I'll be back with details. Thanks.
          Hide
          Babak Vahdat added a comment - - edited

          @Hadrian,

          I'm afraid I was wrong with my assumption as I didn't check [1] before commenting on this ticket where the default value of contentDivClass member variable of the Mojo HtmlToPdfMojo gets overriden with the one injected through the plugin configuration, that's 'wiki-content maincontent':

                   <plugin>
                      <groupId>org.apache.camel</groupId>
                      <artifactId>maven-html-to-pdf</artifactId>
                      <version>${project.version}</version>
                      <executions>
                        <execution>
                          <goals>
                            <goal>compile</goal>
                          </goals>
                          <phase>compile</phase>
                        </execution>
                      </executions>    
                      <configuration>
                        <page>http://camel.apache.org/book-in-one-page.html</page>
                        <contentDivClass>wiki-content maincontent</contentDivClass>
                        <head><![CDATA[ 
                            <link href="file:${basedir}/src/styles/print.css" rel="stylesheet" type="text/css" />
                            <style type="text/css">
                              @page :left {
                                @top-left {
                                  content: "Apache Camel ${project.version} Developer's Manual";
                                }
                              }
                            </style>
                        ]]></head>
                        <replaceToken><![CDATA[
                            <h3 id="replaceme">.*</h3>
                        ]]></replaceToken>
                        <replaceValue><![CDATA[
                            <h3>Version ${project.version}</h3>
                        ]]></replaceValue>
                      </configuration>
                    </plugin>
          

          If what I claimed was right it should have always systematically failed which is apparently not the case. Still looking into it in the hope of some findings.

          [1] https://svn.apache.org/repos/asf/camel/trunk/tooling/camel-manual/pom.xml

          Show
          Babak Vahdat added a comment - - edited @Hadrian, I'm afraid I was wrong with my assumption as I didn't check [1] before commenting on this ticket where the default value of contentDivClass member variable of the Mojo HtmlToPdfMojo gets overriden with the one injected through the plugin configuration, that's 'wiki-content maincontent': <plugin> <groupId>org.apache.camel</groupId> <artifactId>maven-html-to-pdf</artifactId> <version>${project.version}</version> <executions> <execution> <goals> <goal>compile</goal> </goals> <phase>compile</phase> </execution> </executions> <configuration> <page>http: //camel.apache.org/book-in-one-page.html</page> <contentDivClass>wiki-content maincontent</contentDivClass> <head><![CDATA[ <link href= "file:${basedir}/src/styles/print.css" rel= "stylesheet" type= "text/css" /> <style type= "text/css" > @page :left { @top-left { content: "Apache Camel ${project.version} Developer's Manual" ; } } </style> ]]></head> <replaceToken><![CDATA[ <h3 id= "replaceme" >.*</h3> ]]></replaceToken> <replaceValue><![CDATA[ <h3>Version ${project.version}</h3> ]]></replaceValue> </configuration> </plugin> If what I claimed was right it should have always systematically failed which is apparently not the case. Still looking into it in the hope of some findings. [1] https://svn.apache.org/repos/asf/camel/trunk/tooling/camel-manual/pom.xml
          Hide
          Hadrian Zbarcea added a comment -

          Yeah, it's even a bit worse than that. If you try to validate the pages using a validator (like the w3c one) there are a bunch of errors in the generated html pages that need fixing. They didn't get high on my priority list because at some point we were discussing other/better ways of providing docs.

          Show
          Hadrian Zbarcea added a comment - Yeah, it's even a bit worse than that. If you try to validate the pages using a validator (like the w3c one) there are a bunch of errors in the generated html pages that need fixing. They didn't get high on my priority list because at some point we were discussing other/better ways of providing docs.
          Hide
          Babak Vahdat added a comment - - edited
          Show
          Babak Vahdat added a comment - - edited My post seems not to get accepted so that I simply paste the Nabble link into here: http://camel.465427.n5.nabble.com/svn-commit-r1205412-camel-trunk-tooling-maven-maven-html-to-pdf-src-main-java-org-apache-camel-mavena-td5016786.html
          Hide
          Babak Vahdat added a comment -

          As I've already claimed by this ticket, trying:

          mvn release:prepare -DdryRun=true 
          

          failes beforehand by me @ maven-gpg-plugin because of the missing public key of mine in [1]. So that I can't even reproduce the issue on my box. I think even better than "mvn -X ..." one could attach (remotely through IDE) to the maven process with something like:

          MAVEN_OPTS = ... -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044
          

          And then one could follow the exception chain completely down to the root cause where it's thrown. However "mvn -X ..." on the other hand would dump something like:

          ...
           Caused by: ...
                   ... 27 more
          ...
          .....
           Caused by: ...
                   ... 9 more
          ...
          

          into the console which wouldn't really give a clue where/why it has been thrown. Having the exact point where it's thrown would then give us a good clue for further investigation. Regarding the puzzle why "mvn install" works but not "mvn release" I suspect that the classpath setup through maven are different in those cases, one with Xerces and/or Xalan and one without, which seem to have some issues see [2] & [3] and also the comments in [4].

          In worst case I think we should move towards something else other than Tagsoup. The ones I'm aware of are:

          • NekoHTML
          • HtmlCleaner
          • jTidy

          I'll try to reproduce the behaviour using some of my own Apps but without much hope

          [1] https://svn.apache.org/repos/asf/camel/trunk/KEYS
          [2] http://osdir.com/ml/text.xml.xforms.chiba.devel/2005-03/msg00068.html
          [3] http://apache-tika-users.1629097.n2.nabble.com/Xerces-Xalan-x-marks-the-spot-td3791968.html
          [4] https://svn.apache.org/repos/asf/camel/trunk/components/camel-tagsoup/pom.xml
          Babak

          Show
          Babak Vahdat added a comment - As I've already claimed by this ticket, trying: mvn release:prepare -DdryRun= true failes beforehand by me @ maven-gpg-plugin because of the missing public key of mine in [1] . So that I can't even reproduce the issue on my box. I think even better than "mvn -X ..." one could attach (remotely through IDE) to the maven process with something like: MAVEN_OPTS = ... -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 And then one could follow the exception chain completely down to the root cause where it's thrown. However "mvn -X ..." on the other hand would dump something like: ... Caused by: ... ... 27 more ... ..... Caused by: ... ... 9 more ... into the console which wouldn't really give a clue where/why it has been thrown. Having the exact point where it's thrown would then give us a good clue for further investigation. Regarding the puzzle why "mvn install" works but not "mvn release" I suspect that the classpath setup through maven are different in those cases, one with Xerces and/or Xalan and one without, which seem to have some issues see [2] & [3] and also the comments in [4] . In worst case I think we should move towards something else other than Tagsoup. The ones I'm aware of are: NekoHTML HtmlCleaner jTidy I'll try to reproduce the behaviour using some of my own Apps but without much hope [1] https://svn.apache.org/repos/asf/camel/trunk/KEYS [2] http://osdir.com/ml/text.xml.xforms.chiba.devel/2005-03/msg00068.html [3] http://apache-tika-users.1629097.n2.nabble.com/Xerces-Xalan-x-marks-the-spot-td3791968.html [4] https://svn.apache.org/repos/asf/camel/trunk/components/camel-tagsoup/pom.xml Babak
          Hide
          Willem Jiang added a comment -

          Hi Babak

          I can reproduce the error without try to release the camel in the trunk now.
          Did you try to reproduce the error by just using mvn clean install ?

          Show
          Willem Jiang added a comment - Hi Babak I can reproduce the error without try to release the camel in the trunk now. Did you try to reproduce the error by just using mvn clean install ?
          Hide
          Babak Vahdat added a comment - - edited

          Hi Willem,

          doing

          mvn clean install
          

          worked fine on my box yesterday night which created a proper PDF I'll try to do install again tonight @ home and will attach the generated PDF into this ticket.

          Have you installed prince [1] on your box (I've got version 8 of it) and do you have it properly on PATH? This is imporant for a proper PDF generation through maven-html-to-pdf plugin, however this has not been mentioned in [2].

          [1] http://www.princexml.com
          [2] http://camel.apache.org/release-guide.html

          Babak

          Show
          Babak Vahdat added a comment - - edited Hi Willem, doing mvn clean install worked fine on my box yesterday night which created a proper PDF I'll try to do install again tonight @ home and will attach the generated PDF into this ticket. Have you installed prince [1] on your box (I've got version 8 of it) and do you have it properly on PATH? This is imporant for a proper PDF generation through maven-html-to-pdf plugin, however this has not been mentioned in [2] . [1] http://www.princexml.com [2] http://camel.apache.org/release-guide.html Babak
          Hide
          Willem Jiang added a comment -

          Hi Babak

          I tried run mvn clean install on the tooling/camel-manual/, I got the same failure when I used mvn 2.2.1 and 3.0.2.

          Using Java version: 1.6.0
          Apache Maven 2.2.1 (r801777; 2009-08-07 03:16:01+0800)
          Java version: 1.6.0_26
          Java home: /Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home
          
          Show
          Willem Jiang added a comment - Hi Babak I tried run mvn clean install on the tooling/camel-manual/, I got the same failure when I used mvn 2.2.1 and 3.0.2. Using Java version: 1.6.0 Apache Maven 2.2.1 (r801777; 2009-08-07 03:16:01+0800) Java version: 1.6.0_26 Java home: /Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home
          Hide
          Babak Vahdat added a comment - - edited

          Hi Willem,

          My maven setup is:

          D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual>mvn --version
          Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
          Maven home: P:\My Documents\dev\env\apache-maven-3.0.3\bin\..
          Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
          Java home: C:\Program Files\Java\jdk1.6.0_29\jre
          Default locale: de_CH, platform encoding: Cp1252
          OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
          

          And when I do mvn clean install on tooling/camel-manual, I get the following output:

          [INFO] Downloading: http://camel.apache.org/book-in-one-page.html
          [INFO] Stored: D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target/site/manual/camel-manual-2.9-SNAPSHOT.html
          [INFO] Converting to PDF with prince...
          [INFO] About to execute PrinceXml (see www.princexml.com)
          [INFO]  prince D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target/site/manual/camel-manual-2.9-SNAPSHOT.html D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target/site/manual/camel-manual-2.9-SNAPSHOT.pdf
          [INFO]
          [INFO] --- build-helper-maven-plugin:1.5:attach-artifact (attach-artifacts) @ camel-manual ---
          [INFO]
          [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ camel-manual ---
          [INFO]
          [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ camel-manual ---
          [INFO] Installing D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\pom.xml to D:\Data\Maven\repo\org\apache\camel\camel-manual\2.9-SNAPSHOT\camel-manual-2.9-SNAPSHOT.pom
          [INFO] Installing D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target\site\manual\camel-manual-2.9-SNAPSHOT.pdf to D:\Data\Maven\repo\org\apache\camel\camel-manual\2.9-SNAPSHOT\camel-manual-2.9-SNAPSHOT.pdf
          

          Which produces a proper readable PDF

          Please note that I edited my previous post on this ticket with some more informations about princexml. Could you check it please?

          On windows before I do mvn clean install inside terminal I put prince.exe into the Windows PATH variable, that's:

          PATH=%PATH%;P:\My Documents\dev\env\prince\Engine\bin
          

          On Unix / Mac (I assume) it would be something like

          export PATH=$PATH:<path_to_your_princexml_installation>/Engine/bin
          

          After setting the PATH properly then I do mvn clean install, which as said before creates the PDF properly. You can download princexml @ [1]

          [1] http://www.princexml.com/download/

          Babak

          Show
          Babak Vahdat added a comment - - edited Hi Willem, My maven setup is: D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual>mvn --version Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: P:\My Documents\dev\env\apache-maven-3.0.3\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_29\jre Default locale: de_CH, platform encoding: Cp1252 OS name: "windows xp" , version: "5.1" , arch: "x86" , family: "windows" And when I do mvn clean install on tooling/camel-manual, I get the following output: [INFO] Downloading: http: //camel.apache.org/book-in-one-page.html [INFO] Stored: D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target/site/manual/camel-manual-2.9-SNAPSHOT.html [INFO] Converting to PDF with prince... [INFO] About to execute PrinceXml (see www.princexml.com) [INFO] prince D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target/site/manual/camel-manual-2.9-SNAPSHOT.html D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target/site/manual/camel-manual-2.9-SNAPSHOT.pdf [INFO] [INFO] --- build-helper-maven-plugin:1.5:attach-artifact (attach-artifacts) @ camel-manual --- [INFO] [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files ( default ) @ camel-manual --- [INFO] [INFO] --- maven-install-plugin:2.3.1:install ( default -install) @ camel-manual --- [INFO] Installing D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\pom.xml to D:\Data\Maven\repo\org\apache\camel\camel-manual\2.9-SNAPSHOT\camel-manual-2.9-SNAPSHOT.pom [INFO] Installing D:\Data\eclipse-workspace\camel-trunk\tooling\camel-manual\target\site\manual\camel-manual-2.9-SNAPSHOT.pdf to D:\Data\Maven\repo\org\apache\camel\camel-manual\2.9-SNAPSHOT\camel-manual-2.9-SNAPSHOT.pdf Which produces a proper readable PDF Please note that I edited my previous post on this ticket with some more informations about princexml. Could you check it please? On windows before I do mvn clean install inside terminal I put prince.exe into the Windows PATH variable, that's: PATH=%PATH%;P:\My Documents\dev\env\prince\Engine\bin On Unix / Mac (I assume) it would be something like export PATH=$PATH:<path_to_your_princexml_installation>/Engine/bin After setting the PATH properly then I do mvn clean install, which as said before creates the PDF properly. You can download princexml @ [1] [1] http://www.princexml.com/download/ Babak
          Hide
          Babak Vahdat added a comment -

          @Willem

          Just checked the MacOS distribution for princexml @ [1]. The installation steps there seem to be different.
          So please check 'install.sh' & 'README.TXT' inside it.

          [1] http://www.princexml.com/download/prince-8.0-macosx.tar.gz

          Babak

          Show
          Babak Vahdat added a comment - @Willem Just checked the MacOS distribution for princexml @ [1] . The installation steps there seem to be different. So please check 'install.sh' & 'README.TXT' inside it. [1] http://www.princexml.com/download/prince-8.0-macosx.tar.gz Babak
          Hide
          Babak Vahdat added a comment -

          @Willem,

          as already promised I attached the generated PDF on my box (camel-manual-2.9-SNAPSHOT.pdf) into this ticket. The odd thing I realized is that all chapters by the second page (Table Of Contents) point to "Chapter 1". Nevertheless it's still a proper and readable PDF.

          Maybe you should check your setup regarding princexml installation, see my previous posts regarding this by this ticket. Could you maybe paste the maven output when you do mvn clean install on tooling/camel-manual?

          Babak

          Show
          Babak Vahdat added a comment - @Willem, as already promised I attached the generated PDF on my box (camel-manual-2.9-SNAPSHOT.pdf) into this ticket. The odd thing I realized is that all chapters by the second page (Table Of Contents) point to "Chapter 1". Nevertheless it's still a proper and readable PDF. Maybe you should check your setup regarding princexml installation, see my previous posts regarding this by this ticket. Could you maybe paste the maven output when you do mvn clean install on tooling/camel-manual? Babak
          Hide
          Hadrian Zbarcea added a comment -

          @Babak, out of curiosity, why did you attach the manual pdf? It can be generated just fine. It's just during the release phase that there is a problem with the download. For all minor releases I generated it manually and uploaded to the staging site.

          Show
          Hadrian Zbarcea added a comment - @Babak, out of curiosity, why did you attach the manual pdf? It can be generated just fine. It's just during the release phase that there is a problem with the download. For all minor releases I generated it manually and uploaded to the staging site.
          Hide
          Babak Vahdat added a comment -

          @Hadrain, just to make Willem believe that the pdf generation works on my box during the install! Apparently even that seems not to work on his box.

          Show
          Babak Vahdat added a comment - @Hadrain, just to make Willem believe that the pdf generation works on my box during the install! Apparently even that seems not to work on his box.
          Hide
          Babak Vahdat added a comment -

          @Hadrian

          As I can't reproduce the issue on my box (see my previous comments because of the maven-gpg-plugin) would it be possible for you to do:

          mvn -X -DdryRun=true release:prepare > camel-3774.log
          

          and attach the output on this ticket, so that I can get some clue about the problem cause?

          Show
          Babak Vahdat added a comment - @Hadrian As I can't reproduce the issue on my box (see my previous comments because of the maven-gpg-plugin) would it be possible for you to do: mvn -X -DdryRun= true release:prepare > camel-3774.log and attach the output on this ticket, so that I can get some clue about the problem cause?
          Hide
          Babak Vahdat added a comment -

          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

          mvn clean install -Dtest=foo
          

          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

          com.sun.org.apache.xerces.internal.dom.AttrImpl   
          

          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

          /Users/bvahdat/dev/prince   
          

          And before calling maven I did

          PATH=$PATH:/Users/bvahdat/dev/prince/bin
          

          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

          mvn clean install
          

          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

          Show
          Babak Vahdat added a comment - 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 mvn clean install -Dtest=foo 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 com.sun.org.apache.xerces.internal.dom.AttrImpl 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 /Users/bvahdat/dev/prince And before calling maven I did PATH=$PATH:/Users/bvahdat/dev/prince/bin 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 mvn clean install 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
          Hide
          Hadrian Zbarcea added a comment -

          @Babak, my findings are different than yours. For me, the PDF manual gets generated properly from both [1] and [2] (your links). It's just during release:* when the generation fails, and the configuration seems to be the same (although something is clearly different as the generation fails only during release). I will test your findings on both osx and linux though. Thanks!

          Show
          Hadrian Zbarcea added a comment - @Babak, my findings are different than yours. For me, the PDF manual gets generated properly from both [1] and [2] (your links). It's just during release:* when the generation fails, and the configuration seems to be the same (although something is clearly different as the generation fails only during release). I will test your findings on both osx and linux though. Thanks!
          Hide
          Babak Vahdat added a comment - - edited

          @Hadrian, just right before I gave it a test on my Windows box as well with a consistent result compared to my Mac box, that's without the provided patch while doing

          mvn clean install -Dtest=foo
          

          on [1] I get:

          [INFO] --- maven-html-to-pdf:2.10-SNAPSHOT:compile (default) @ camel-manual ---
          [INFO] Downloading: http://camel.apache.org/book-in-one-page.html
          FEHLER:  'NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.'
          [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] Stored dummy file: C:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.html since download of http://camel.apache.org/book-in-one-page.html failed.
          

          And with the patch applied on my workspace I get:

          [INFO] --- maven-html-to-pdf:2.10-SNAPSHOT:compile (default) @ camel-manual ---
          [INFO] Set the XSL transformer factory class name to be 'org.apache.xalan.xsltc.trax.TransformerFactoryImpl'
          [INFO] Downloading: http://camel.apache.org/book-in-one-page.html
          [INFO] Removed the set XSL transformer factory class name 'org.apache.xalan.xsltc.trax.TransformerFactoryImpl' from the system properties
          [INFO] Stored: c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.html
          [INFO] Converting to PDF with prince...
          [INFO] About to execute PrinceXml (see www.princexml.com)
          [INFO]  prince c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.html c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.pdf
          [INFO] Stored: c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.pdf
          

          Where the generated zip & tar artifacts both contain a proper HTML & PDF copy of the manual. For any case I put my workspace setup just in the case you may want to compare with yours:

          Windows:

          c:\dev\workspace\camel>mvn -verrsion
          Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
          Maven home: c:\dev\apache-maven-3.0.3\bin\..
          Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
          Java home: c:\dev\jdk1.6\jre
          Default locale: de_CH, platform encoding: Cp1252
          OS name: "windows vista", version: "6.0", arch: "x86", family: "windows"
          

          MacOS:

          ~/dev/workspace/camel>mvn -version
          Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
          Maven home: /usr/share/maven
          Java version: 1.6.0_29, vendor: Apple Inc.
          Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
          Default locale: de_DE, platform encoding: MacRoman
          OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
          
          

          [1] https://svn.apache.org/repos/asf/camel/trunk/

          Show
          Babak Vahdat added a comment - - edited @Hadrian, just right before I gave it a test on my Windows box as well with a consistent result compared to my Mac box, that's without the provided patch while doing mvn clean install -Dtest=foo on [1] I get: [INFO] --- maven-html-to-pdf:2.10-SNAPSHOT:compile ( default ) @ camel-manual --- [INFO] Downloading: http: //camel.apache.org/book-in-one-page.html FEHLER: 'NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.' [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] Stored dummy file: C:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.html since download of http: //camel.apache.org/book-in-one-page.html failed. And with the patch applied on my workspace I get: [INFO] --- maven-html-to-pdf:2.10-SNAPSHOT:compile ( default ) @ camel-manual --- [INFO] Set the XSL transformer factory class name to be 'org.apache.xalan.xsltc.trax.TransformerFactoryImpl' [INFO] Downloading: http: //camel.apache.org/book-in-one-page.html [INFO] Removed the set XSL transformer factory class name 'org.apache.xalan.xsltc.trax.TransformerFactoryImpl' from the system properties [INFO] Stored: c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.html [INFO] Converting to PDF with prince... [INFO] About to execute PrinceXml (see www.princexml.com) [INFO] prince c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.html c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.pdf [INFO] Stored: c:\dev\workspace\camel\tooling\camel-manual\target/site/manual/camel-manual-2.10-SNAPSHOT.pdf Where the generated zip & tar artifacts both contain a proper HTML & PDF copy of the manual. For any case I put my workspace setup just in the case you may want to compare with yours: Windows: c:\dev\workspace\camel>mvn -verrsion Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: c:\dev\apache-maven-3.0.3\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: c:\dev\jdk1.6\jre Default locale: de_CH, platform encoding: Cp1252 OS name: "windows vista" , version: "6.0" , arch: "x86" , family: "windows" MacOS: ~/dev/workspace/camel>mvn -version Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /usr/share/maven Java version: 1.6.0_29, vendor: Apple Inc. Java home: / System /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: de_DE, platform encoding: MacRoman OS name: "mac os x" , version: "10.7.2" , arch: "x86_64" , family: "mac" [1] https://svn.apache.org/repos/asf/camel/trunk/
          Hide
          Babak Vahdat added a comment -

          @Hadrian, as Christian intends to cut the last 2.7.x branch release by this freiday 01/06/2011 that's not much time left.
          I believe the provided patch does the trick, but the last proof would be using it while doing a dry run of the release.

          I think we all would love to see a proper HTML & PDF by the next 2.7.5 release tar ball. See also my previous post of the last night after yours.

          Show
          Babak Vahdat added a comment - @Hadrian, as Christian intends to cut the last 2.7.x branch release by this freiday 01/06/2011 that's not much time left. I believe the provided patch does the trick, but the last proof would be using it while doing a dry run of the release. I think we all would love to see a proper HTML & PDF by the next 2.7.5 release tar ball. See also my previous post of the last night after yours.
          Hide
          Babak Vahdat added a comment - - edited

          Right before I had a chat with Hadrian on IRC-Room which partially was:

          [22:22]
          "
          “Hadrian just something came to my mind, may I ask you something?,”
          "
          asked bvahdat.
          [22:22]
          "
          “shoot,”
          "
          said hadrian.
          [22:24]
          "
          “On the ticket CAMEL-3774 you claimed always that "the generation fails only during release". Now I don't get it at all!!!,”
          "
          exclaimed bvahdat.
          [22:25]
          "
          “bvahdat: you said it yourself: when you go to tooling/camel-manual and run `mvn install` the generation passes,”
          "
          said hadrian.
          [22:26]
          "
          “that's how i generated: http://camel.apache.org/manual/camel-manual-2.9.0.pdf,”
          "
          said hadrian.
          [22:26]
          "
          “O.K. I see,”
          "
          said bvahdat.
          [22:27]
          "
          “Was the output again "'NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.'" Or something else?,”
          "
          

          @Hadrian, but when I read your comment on this ticket again at 03/Jan/12 17:08 you said that:

          my findings are different than yours. For me, the PDF manual gets generated properly from both [1] and [2] (your links). It's just during release:* when the generation fails
          

          Now I don't really get it now if / when it works / doesn't work on your box! Please help me understand it. Thanks!

          Show
          Babak Vahdat added a comment - - edited Right before I had a chat with Hadrian on IRC-Room which partially was: [22:22] " “Hadrian just something came to my mind, may I ask you something?,” " asked bvahdat. [22:22] " “shoot,” " said hadrian. [22:24] " “On the ticket CAMEL-3774 you claimed always that "the generation fails only during release" . Now I don't get it at all!!!,” " exclaimed bvahdat. [22:25] " “bvahdat: you said it yourself: when you go to tooling/camel-manual and run `mvn install` the generation passes,” " said hadrian. [22:26] " “that's how i generated: http: //camel.apache.org/manual/camel-manual-2.9.0.pdf,” " said hadrian. [22:26] " “O.K. I see,” " said bvahdat. [22:27] " “Was the output again "'NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.'" Or something else ?,” " @Hadrian, but when I read your comment on this ticket again at 03/Jan/12 17:08 you said that: my findings are different than yours. For me, the PDF manual gets generated properly from both [1] and [2] (your links). It's just during release:* when the generation fails Now I don't really get it now if / when it works / doesn't work on your box! Please help me understand it. Thanks!
          Hide
          Hadrian Zbarcea added a comment -

          Babak, after wiping out my local maven repo your patch seems to be working on Linux. I tested and committed on branches 2.7.x up to trunk. I am currently running a release dryRun on osx, which I had to restart due to a checkstyle error. We will know more in the morning, and hopefully be able to close this issue. Thanks again for taking the time.

          Show
          Hadrian Zbarcea added a comment - Babak, after wiping out my local maven repo your patch seems to be working on Linux. I tested and committed on branches 2.7.x up to trunk. I am currently running a release dryRun on osx, which I had to restart due to a checkstyle error. We will know more in the morning, and hopefully be able to close this issue. Thanks again for taking the time.
          Hide
          Hadrian Zbarcea added a comment -

          The release dryRun went fine on osx. I have no reason to believe it won't work on other platforms. I will mark this issue as resolved. Thanks again Babak for the patch.

          Show
          Hadrian Zbarcea added a comment - The release dryRun went fine on osx. I have no reason to believe it won't work on other platforms. I will mark this issue as resolved. Thanks again Babak for the patch.

            People

            • Assignee:
              Hadrian Zbarcea
              Reporter:
              Hadrian Zbarcea
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development