Kevin, I've been doing this sort of production for some time now, using the DITA plugin for Maven - http://mojo.codehaus.org/dita-maven-plugin/index.html Several chapters are built automatically during the software build process, as you suggest. For this, I have written my own Maven modules that parse Java source files and serialised java object files. The dita is generated using xdoc library - http://maven.apache.org/doxia/references/xdoc-format.html
Our maven modules build dita topic files and ditamaps. We also post-process some of the dita files with software version information etc, using standard Maven plugins, before calling the DITA-OT from the Maven plugin. However, I still author most of the chapters using XMLmind editor, and do quick checks of PDFs using its inbuilt ditac convertor. This way, the authoring is decoupled from the build process. Different authors can use their preferred DITA editor. The final build is all done via Apache 2 licensed products and can be run either on the central build server or locally by individual developers without licensing issues. On 2010-10-20, at 6:00 PM, Kevin Flynn wrote: > There's another reason why integration of XmlMind with SW versioning > systems would be a good idea: > > Storing SW documentation in the same versioning system as the SW being > documented enables very tight integration of the SW and documentation > build process. I have been documenting SW in this way (using XmlMind) > for the last 8 years, in two different companies, and find it hard to > imagine working any other way. > > Basically, the documentation staff are able to "piggyback" on the SW > team's versioning mechanisms, and rarely have to think about it. > Similarly, we don't have to think about documentation production: the > documentation is built when the SW is built, and automatically packaged > with it. The documentation build process (driven, in our case either by > ant or by xproc+maven) has direct access to lots of information in > source files, XML schemas, configuration files, GUI definition files and > so on, and can therefore easily integrate auto-generated documentation > with hand-written documentation. Version numbers are just a parameter in > from the build process and can never be wrong. References to GUI labels > can be references to the actual label definitions in some (probably XML) > configuration file, so they also can't be wrong (a mismatch stops the > build). > > The result (after the initial effort) is less work to do and a lot of > built-in quality control. > > I have absolutely no idea how many SW documentation teams work this way, > but I can't believe the two that I have worked in over the last 8 years > are the only ones. Integration of XmlMind with Perforce (in my case) > would be nice, and worth an upgrade. > > Kevin Flynn > Vizrt > Oslo, Norway > > > On 10/19/2010 09:45 PM, Hussein Shafie wrote: >> On 10/19/2010 08:30 PM, David Priest wrote: >> >>> [blink] >>> >>> I think revisioning tools are *essential* for technical writers. Anyone >>> who isn't using a revisioning tool is absolutely foolish, in my opinion. >>> >>> Obviously, your opinion differs. >>> >>> It may be most wise to survey the domain, to find out whether your >>> assumption is correct. I simply can't imagine trying to manage a large >>> and complicated writing project without some sort of ability to claw >>> back changes and mistakes. >>> >> We agree that's why we have developed XMLmind Document Repository. >> >> --- >> XMLmind Document Repository >> >> Just enough versioning for the technical writer >> >> XMLmind Document Repository is a web-based document store featuring >> automatic, transparent, versioning. It is a compromise between the >> simplicity of a shared folder and the power of a revision control system >> (CVS, Subversion, etc). This compromise between simplicity and power >> aims to be well-adapted to the needs of the technical writer. >> --- >> >> See http://www.xmlmind.com/docrep/ >> >> >> >> >>> Hussein Shafie wrote: >>> >>>> we think that these programmers tools are >>>> overkill, much too complicated to use for technical writers. >>>> >> >> >> >> -- >> XMLmind XML Editor Support List >> [email protected] >> http://www.xmlmind.com/mailman/listinfo/xmleditor-support >> >> > > > -- > XMLmind XML Editor Support List > [email protected] > http://www.xmlmind.com/mailman/listinfo/xmleditor-support -- XMLmind XML Editor Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
