Coderef elements not being copied to temp directory

58 views
Skip to first unread message

Lief Erickson

unread,
Sep 10, 2015, 7:53:35 PM9/10/15
to DITA-OT Users
Hello--

This is a continuation of an issue I raised on the dita-users list here: https://groups.yahoo.com/neo/groups/dita-users/conversations/messages/38312. I'm moving this discussion here in hopes of attracting greater elaboration from OT users/developers. (Kendall, your workaround that you offered didn't work in my situation, but I appreciated the pointer; it helped me further my investigation.)

With OT 2.1.1 coderef elements are not appearing in my output. In particular, they're not being copied to the temp directory and because they're not found in the temp directory they're not included in the final output. My issue is very specific to coderef, and, in particular, coderef elements that would be considered "outer" to the topic and map files because images from the same "outer" directory are being copied. The errors are:

[topicfragment][coderef][DOTJ051E][ERROR] Unable to load target for coderef.
[gen-list] [DOTJ013E][ERROR] Failed to parse the referenced file 

I believe this comment/commit by @jelovirt on May 24, 2015 is the source for the issue. 
Commit comment: Remove subsidiary list from Ant and retrieve from source in coderef 

In build_preprocess_template.xml line 557 had 'copy-subsidiary' removed but there was nothing added for to handle the copying of coderef (e.g., copy-coderef). Should there have been?

Before: dita:depends="{depend.preprocess.copy-files.pre},copy-image,copy-html,copy-flag,copy-subsidiary"
After: dita:depends="{depend.preprocess.copy-files.pre},copy-image,copy-html,copy-flag"

I don't see any target in the build_preprocess_template.xml file that copies coderef elements. Is this an oversight?

Jarno, if you're reading this, were "outer" files tested with your commit on May 24? If you can recall, were they tested with generate.copy.outer=3? 

OT 2.1.1 + generate.copy.outer=1 == SUCCESS
OT 2.1.1 + generate.copy.outer=3 == FAIL

OT 1.8.5 + generate.copy.outer=1 == SUCCESS
OT 1.8.5 + generate.copy.outer=3 == SUCCESS

Before I open a new issue on github I want some confirmation about how things are supposed to work if generate.copy.outer=3 is used. I am not experiencing the behavior documented for generate.copy.outer at http://www.dita-ot.org/2.1/parameters/generate-copy-outer.html.

Can someone clarify? 

Are coderefs not being copied to the temp directory a duplicate of https://github.com/dita-ot/dita-ot/issues/1762 or a new issue?

-Lief

Kendall Shaw

unread,
Sep 10, 2015, 8:07:47 PM9/10/15
to DITA-OT Users
Hi,

Part of the problem when I looked into it was that DITA-OT was parsing the targets of the coderefs.


This got fixed in this commit in the development branch:


I have been looking into what the non-deprecated equivalent of copy-subsidiary is, so thanks for asking.

Meanwhile, if you can use the revision above, then you could use the kludge that I offered,, which essentially duplicates the deprecated copy-subsidiary target.

There is a pull request for tests of the above revision:


Kendall
--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Kendall Shaw

unread,
Sep 10, 2015, 10:10:51 PM9/10/15
to DITA-OT Users
I think my comment is not worded very clearly.

I saw what you are reporting, that the coderef targets are not appearing in the temp directory, let alone the output directory.

What I found was that the gen-list module was parsing the targets as if they were XML. So, I submitted a fix that at least gets them into the product of the gen-list module, so that something like the copy-subsidiary target could be used. This became the commit listed below:
In other words, if you use the development branch, you could then use the copy-subsidiary target and then add code to copy from temp into your output, or use the kludge that I suggested, to get your non-image files into the output.

But, this is the deprecated way, I think. I want, we collectively want to know what the non-deprecated way is that Jarno probably has in mind. So, I am eager to hear an answer to that.

Meanwhile, if you can't use the development branch, but you can build source code, you change the one line of code in the commit listed above to then have json files referred to by the the subtargets.list file.

Kendall

Jarno Elovirta

unread,
Sep 11, 2015, 1:48:33 AM9/11/15
to Kendall Shaw, DITA-OT Users
J

--

Lief Erickson

unread,
Sep 11, 2015, 9:21:17 AM9/11/15
to Jarno Elovirta, Kendall Shaw, DITA-OT Users
I cherry picked the fix to my local 2.1.1 branch and rebuilt dost.jar. I can confirm that I am getting the output I expect now. Thank you!

-Lief
Reply all
Reply to author
Forward
0 new messages