Derby
  1. Derby
  2. DERBY-5349

Clean docs build fails to pick up customized map2htmtoc.xsl

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Documentation
    • Labels:
      None

      Description

      If I try to build the documentation from a clean checkout, or after running "ant clobber", the customized map2htmtoc.xsl file isn't picked up. This means for example that the fix for DERBY-5205 is missing, and the toc.html file doesn't have a lang attribute.

      When running "ant -v -lib lib/fop.jar html.getstart", I see this line in output from ant:

      [copy] /code/derby/docs/clean-trunk/lib/map2htmtoc.xsl omitted as /code/derby/docs/clean-trunk/DITA-OT1.1.2.1/xsl/map2htmtoc.xsl is up to date.

        Issue Links

          Activity

          Hide
          Kim Haase added a comment -

          You are right, I see this too now when I do a clobber. I think the same thing happened with the dita2htmlImpl.xsl file a few months ago. It was some sort of timing issue, and we resolved it by adding the overwrite="true" option to the copy target. I tried this with the map2htmtoc file –

          <copy file="$

          {dita.lib.dir}

          /map2htmtoc.xsl" todir="$

          {dita.dir}

          /xsl" overwrite="true"/>

          and it seems to do the trick. I will revise the DERBY-4408 patch once again.

          Show
          Kim Haase added a comment - You are right, I see this too now when I do a clobber. I think the same thing happened with the dita2htmlImpl.xsl file a few months ago. It was some sort of timing issue, and we resolved it by adding the overwrite="true" option to the copy target. I tried this with the map2htmtoc file – <copy file="$ {dita.lib.dir} /map2htmtoc.xsl" todir="$ {dita.dir} /xsl" overwrite="true"/> and it seems to do the trick. I will revise the DERBY-4408 patch once again.
          Hide
          Knut Anders Hatlen added a comment -

          It appears to work. I'm just puzzled that the timestamp of the map2htmtoc.xsl file is updated earlier in the build (which is why the file is believed to be up to date). Perhaps the build process makes some other customizations that may get overwritten when we copy our updated version later. We should look into that before we close this issue.

          Show
          Knut Anders Hatlen added a comment - It appears to work. I'm just puzzled that the timestamp of the map2htmtoc.xsl file is updated earlier in the build (which is why the file is believed to be up to date). Perhaps the build process makes some other customizations that may get overwritten when we copy our updated version later. We should look into that before we close this issue.
          Hide
          Knut Anders Hatlen added a comment -

          The timestamps are updated by this build target:

          <target name="dita.regex" unless="regex.done">
          <replaceregexp match="select="'.xml'"" replace="select="'.dita'"">
          <fileset dir="$

          {dita.script.dir}" includes="*/.xsl"/>
          </replaceregexp>
          <touch file="${dita.script.dir}

          /regex.done"/>
          </target>

          It seems to be replacing '.xml' with '.dita' in all XSL files. Probably because we call our doc files *.dita instead of *.xml, as DITA expects?

          Show
          Knut Anders Hatlen added a comment - The timestamps are updated by this build target: <target name="dita.regex" unless="regex.done"> <replaceregexp match="select="'.xml'"" replace="select="'.dita'""> <fileset dir="$ {dita.script.dir}" includes="* / .xsl"/> </replaceregexp> <touch file="${dita.script.dir} /regex.done"/> </target> It seems to be replacing '.xml' with '.dita' in all XSL files. Probably because we call our doc files *.dita instead of *.xml, as DITA expects?
          Hide
          Kim Haase added a comment -

          I guess that's what's happening – I sort of half figured it out in DERBY-5136 – these files are processed before the copy apparently, so they seem to be up to date. There don't seem to be any ill effects, though.

          Show
          Kim Haase added a comment - I guess that's what's happening – I sort of half figured it out in DERBY-5136 – these files are processed before the copy apparently, so they seem to be up to date. There don't seem to be any ill effects, though.
          Hide
          Knut Anders Hatlen added a comment -

          The fix that went in with DERBY-4408 fixed this issue. Thanks!

          I'm wondering, though, if the proper fix would be to rename all *.dita files to *.xml in the repository and remove the dita.regex build target that's causing this problem. After all, .xml is the extension DITA seems to be expecting, and then we could build the docs with a less modified version of DITA, which would probably be easier to maintain. And we could simplify the instructions on how to work on the docs, as setting default svn:eol-style for *.dita wouldn't be necessary anymore.

          In any case, the fix that went in with DERBY-4408 fixed this immediate issue, and I've verified that the fix works, so I'm closing the bug.

          Show
          Knut Anders Hatlen added a comment - The fix that went in with DERBY-4408 fixed this issue. Thanks! I'm wondering, though, if the proper fix would be to rename all *.dita files to *.xml in the repository and remove the dita.regex build target that's causing this problem. After all, .xml is the extension DITA seems to be expecting, and then we could build the docs with a less modified version of DITA, which would probably be easier to maintain. And we could simplify the instructions on how to work on the docs, as setting default svn:eol-style for *.dita wouldn't be necessary anymore. In any case, the fix that went in with DERBY-4408 fixed this immediate issue, and I've verified that the fix works, so I'm closing the bug.
          Hide
          Kim Haase added a comment -

          Knut, that's a good suggestion, I think, to rename all the doc files .xml instead of .dita. Could you file a JIRA issue for it? Then people could discuss the pros and cons.

          It'd be a big change but might well be worth the trouble.

          Show
          Kim Haase added a comment - Knut, that's a good suggestion, I think, to rename all the doc files .xml instead of .dita. Could you file a JIRA issue for it? Then people could discuss the pros and cons. It'd be a big change but might well be worth the trouble.
          Hide
          Knut Anders Hatlen added a comment -

          I read in the DITA documentation that the toolkit supports both .xml and .dita, and I see that we set dita.extname=.dita in docs.properties, so I filed DERBY-5354 to simply remove the dita.regex build target, which should be a much smaller task.

          Show
          Knut Anders Hatlen added a comment - I read in the DITA documentation that the toolkit supports both .xml and .dita, and I see that we set dita.extname=.dita in docs.properties, so I filed DERBY-5354 to simply remove the dita.regex build target, which should be a much smaller task.

            People

            • Assignee:
              Kim Haase
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development