DITA-OT 2.0: preprocessing step adds to many files to resourceonly.list

[ghost]

In DITA-OT 2.0, a preprocessing step adds files to resourceonly.list that aren't resource-only. In .job.xml these files have the attribute resource-only="true". These topics simply disappear in the output, without any warnings. The CHM compiler complains about missing files but FOP doesn't. I didn't have this problem in DITA-OT 1.8.

Update: DITA-OT 2.0.M3 and 2.0.M4 have this problem, too. In M1 and M2, I ran into other problems and couldn't continue.

Update: This seems to affect topic files that are not referenced by other topic files. When I add one of the missing topic files to the related-links element of an other topic file, the DITA-OT doesn't treat it any more as resource-only. The DITA-OT seems to assume that "isolated" topic files (only mentioned in a ditamap but not in other topic files) are resource-only.

[jelovirt]

I'm unable to reproduce this issue. @maer2712 could you create a Gist for a test set that reproduces the issue in your system?

[ghost]

I tried a couple of times to create a test set but without success. When I remove unrelated files from my file set, the DITA-OT behaves correctly. And I haven't found out yet which of the 1200 unrelated topic files causes the error.

I transformed docsrc/userguide-book.ditamap to PDF: resourceonly.list (in the tmp-directory) contains admin\FixesAndFeatures.xml and admin\HowToParticipate.xml. Technically, this isn't correct because these two files are normal topics. But they belong to the "Project Management" appendix, and that one is commented out. So this isn't a good example.

[ghost]

Three days ago, I wrote that the CHM compiler complains about missing files and FOP doesn't.

In reality, the PDF transform ignores the incorrect "resourceonly.list" file and processes all needed topic files. The CHM (htmlhelp) transform, however, respects the incorrect "resourceonly.list" file. It doesn't copy them to the "out" directory and from that point they are missing.

When I remove the <excludesfiles .../> part in target "dita.inner.topics.html.common" (in file "plugins/org.dita.xhtml/build_general.xml") the necessary topic files get copied and aren't missing anymore. Maybe this could be a work-around, at least for the XHTML based transforms.

[jelovirt]

Regardless of the workaround, I'd need to get a test set of some sort that can be reproduce this issue. In addition of the test set, please add information which properties you set when running DITA-OT.

[ghost]

I have created a test set which should be visible here: https://gist.github.com/maer2712

Structure:

test_root.ditamap
test_maps.ditamap
test_content (directory)
    test_content.ditamap
    dir_01 (directory)
        dir_01.ditamap
        topic_01.dita
        topic_02.dita

I start the transformation by using the "dita" command line tool.

dita -f htmlhelp -i [path]test_root.ditamap -o [path] -temp [path] -v -l [path]antlog.log -Dclean.temp=no -Dhhc.dir="%programfiles%\html help workshop"

In the command above, [path] might be anything one likes.

One doesn't need HTML Help Workshop when testing. The relevant thing is the content of the output directory: in my tests, [outputdirectory]/test_content/dir_01/ contains only topic_02.html, while topic_01.html is missing. Both files should be there. In the project file "test_root.hhp" both topics are listed. In the keyword file "test_root.hhk", topic_01 is missing. In the TOC file "test_root.hhc" both topics are listed.

The main difference between the two topic files is the link from topic_01 to topic_02.

[eerohele]

Fixtures for convenience.

[jelovirt]

Ok, now I was able to reproduce this. It's caused by a combination where all direct references to topics are from a map that was in turn referenced by a keydef element. The keydef has a default processing-role="resource-only" and that gets inherited. Since resource-only references are collected before keys are resolved, the normal processing-roles are never taken into use.

To correct this, processing-roles should collected after conref, keyref, chunk, and metadata cascading processing, in the end of proprocess.

[robander]

It looks like this is the resolved in the latest develop code - not sure when it was last tested so it may also be fixed in an earlier release. (I found it while searching for issues that might overlap #2694, it works with that pull request but also works with latest develop code).

[robander]

Tested in 2.4.6 and this is working there too. So, I'm not sure when this was fixed, but the fix is already available. Marking closed.