I'm trying to build the user guide but I think the files may have been edited and never fixed prior to uploading to Sourceforge. According to the instructions I should be able to run the default build.xml and it will automatically pull in the config files and build the included user guide. Doing so doesn't get very far, because the included confluence.content.xml file is clearly not setup properly (it has as an entire section commented out, and includes this for a contentroot path: path="D:\\projects\\Lombardi\\Working\\sequoyah\\dita2confluence.Herrad\\doc">
Changing that path to match my installation:
doesn't get me much further ahead. Now, when I try to run the build it fails when attempting to find the ditamap DTD (map.dtd). I've attempted the build with the included DTDs and my own (working) set. The path is being constructed improperly, and logs this:
[Dita2Confluence] INFO - Loading ditamap: C:\dita2confluence\doc/userguide/ditamap/using_dita2confluence.ditamap
[Dita2Confluence] org.jdom.input.JDOMParseException: Error on line 2 of document file:/C:/dita2confluence/doc/userguide/ditamap/using_dita2confluence.ditamap: Cannot read from file:///C:\dita2confluence/C:\dita2confluence/files/map.dtd (C:\dita2confluence\C:\dita2confluence\files\map.dtd (The filename, directory name, or volume label syntax is incorrect))
It's clearly picking up the root path twice. How can I fix the path?
Sorry for the inconveniences. Default content file will be fixed and uploaded with a new distribution very soon. Regarding your error with DTD location: did you change the 'dtddir' setting in confluence.config.xml file? For current code version it should be set to "files" if you work with distribution DTDs set or should reflect _relative_ path from D2C installation folder to your working set (e.g. "../MyWorkingSet/dtd"). New code version to be uploaded will determine relative/absolute DTD locations automatically.
Are you running DITA OT 1.3 or later in your environment? We have seen this problem before, and the cause appears to be the classpath settings for DITA OT, which point to the DTD resources along with the required JARs.
Please try the following workaround.
In confluence.config.xml, change:
This causes DITA2Confluence to use the public URIs to the DTD resources, instead of any local DTD resources. Expect performance to be slower b/c you are going over the Web.
If this works for you, it confirms that the problem is caused by DITA OT classpath settings, which point to its copy of the DTD resources and appears to munge the DTD path for any other system using those resources.
Thanks for this help. I'm running OT 126.96.36.199, so that's probably the issue.
Also, I'm glad to see that people are still paying attention to this project. I think it's a pretty useful idea.
I downloaded the latest version of dita2wiki binary, (dita2confluence1.2.2.binary.zip), I have a similar issue can someone show some light ? I also tried the suggestion above to modify the dtddir from files to url, but there is no progress even after a day.
Here is the exception that I receive.
INFO - DTD location: /export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA//export/home/appadmin/DITA/files/
java.io.FileNotFoundException: /export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/files/map.dtd (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
/export/home/appadmin/DITA/build.xml:55: Error running execute:/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/export/home/appadmin/DITA/files/map.dtd (No such file or directory)
I will help you resolve this. Can you pls upload or send me (lisa dot dyer at gmail dot com):
1. a screenshot of your installation directory, showing where the confluence.config.xml and confluence.content.xml files are
2. a copy of your confluence.config.xml and confluence.content.xml files (with any sensitive URL information replaced with foo)
Also, do you have any version of the DITA OT currently installed? If so, any environment variables in your system path that you've configured?
Lisa, have you had an luck with kvnsk's problem? I'm having a very similar issue. I'm trying to move four topic groups from DITA to Confluence. Three of those topic groups (each organized under its own ditamap) convert to Confluence just fine. The last, however, gives me the same type of error kvnsk got. I've tried replacing dtddir with everything I can think of; the URL mentioned in an earlier post, my local copy of the DTDs, the DTDs in the dita2wiki files folder, but to no avail. And it's just this one document. :-(
Any ideas? Here's my environment:
OS: Mac OS 10.5.8
Confluence: 3.0.2 (local eval installation)
Here's my confluence.config.xml (urls changed):
<?xml version="1.0" encoding="UTF-8"?>
and my confluence.content.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module folder="scriptingguide" spacekey="apidoc" spacename="API Documentation"
parentpagetitle="Foo Scripting Guide"
comment="This is a test of dita2confluence." processcontentlabels="true"
wipecomments="true" wipelabels="true" wipespace="false"
sortidstart="5000" sortidend="5999" labels="scripting, foo"/>
Any help would be greatly appreciated; I have no idea why this one ditamap would be causing trouble.
Sometimes writing down the problem is the key to solving it. :-) I found a hint in post #3 of this thread. I needed to remove the DITA-OT-related .jar files from CLASSPATH (e.g., dost.jar, resolver.jar). Once I did this, this ditamap converted just fine using the DTDs packaged with dita2wiki. I still don't know why other ditamaps worked while this one did not, but at least the problem is resolved.
Thanks, Lisa, for making this tool open-source! We're using it as a one-time migration path from DITA to Confluence, and the topic will be maintained in Confluence hereafter. dita2wiki has done a remarkable job of converting the docs cleanly, and made the migration go much faster than expected.
Ah, interesting! I don't recall seeing this particular behavior before where some maps find the DTDs but others don't. Thanks very much for reporting this. I'll update the troubleshooting section in the user guide.
It's so fun to hear about how people are implementing DITA2Wiki. Yours is an interesting use case. Could you talk a bit about your decision-making process to migrate from DITA to wiki? E.g. did usage analytics or customer surveys drive your decision? I think this might be interesting to others in the community to learn about.
Thanks again for sharing.
We adopted DITA about 3.5 years ago at the start of a new software project. Unfortunately, neither our topic count nor our department has grown as much as originally planned, and DITA became more and more unwieldy. Recently, our doc team's management decided that the best option was to move away from authoring DITA and to a wiki-based solution. This actually works better for our customers, who for a long time have wanted to participate more interactively in the documentation process. Frankly, it's also going to be easier for our doc team to author new topics as well. Good news all around. :-)
Anyway, thanks for the tool! I've even had a chance to dive into the source code, since our team wanted indexterms and keywords to convert to labels, and did not want to convert version into a label. I got that change to work in just a couple of hours (pretty good for me). :-)
I seem to be having a similar problem - but using an absolute URl for the dtddir attribute didn't help. Seems the DTD location name is being appended to itself repeatedly. Any ideas out there?
INFO - Loading configuration…
INFO - Configuiration successfully loaded from file confluence.config.xml
INFO - Loading content mapping:
INFO - Loading content root: ./doc/
INFO - Loading module folder ADVANCED_OPS
INFO - DTD location: C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
INFO - DTD location: C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/C:\dita2confluence1.2.2/files/
Do you have DITA OT installed on your system? This looks very much like a known issue with the DITA OT installation (which messes with classpath).
Inspect your environment variables. If you see any classpaths or other system paths that point to files like dost.jar, resolver.jar, remove those from your path, and then try again. Let me know how it goes.
No, that's the odd thing .. there's no OT on this system; and the environment variables and class paths all look quite clean. (It's a clean install with just Confluence and dita2confluence on it). And also, it worked fine for the user guide.
Can you send me a small subset of the DITA src that you can repro this with? Plus the full stack trace. I will investigate.
I was just wondering if you'd got my e-mail, or if you've had a chance to have a look at the stack trace … I still haven't been able to find any obvious cause for this. I'm stumped!
It seems I have the same problem as kevinrorke. I use an absolute path for the dtddir, but the dita2confluence directory keeps being prepended, resulting in an invalid DTD location.
In my case an xref with an e-mail address was the culprit:
<xref href="mailto:email@example.com" scope="external" format="html">firstname.lastname@example.org</xref>
I dug into the source and found the problem to be in the DitaXMLHelper class. When the loading of an XML document throws a FileNotFoundException exception, it assumes this is because of an invalid DTD location. But this is not always the case, because apparantly an xref to an unresolvable e-mail adress also throws a FileNotFoundException exception. I think it should be better to figure out the DTD location up front and not fiddle with it in the process.
More details: dita2confluence 1.2.2, DitaXMLHelper.java, method getXMLFromFile()
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.