You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@infotexture Has there been any discussion in separating Ant script docs into a separate reference? We have
<ditafileset> is our custom resource collection that allows choosing files based on file metadata from Job configuration. It can be used in our custom modules but also with Ant built-in tasks like <copy> or <pathconvert>.
The pipeline task is basically a wrapper around out custom modules and it was added ages ago. In many cases we could change the code and just have the module configuration alone, but it allows use the group modules and e.g. use <xslt> element which is a reserved element name by Ant's built-in tasks.
<module> which is only used with <pipeline> and calls custom or built-in modules, like XsltModule. I don't know if we should list all modules or just those that are general purpose.
Since the dita command was introduced in DITA-OT 2.0, there's been less focus on Ant scripting in the docs.
I'm not necessarily opposed to adding this sort of information, but I'd need more input, as I haven't used Ant in years.
These are not about calling DITA-OT with Ant directly. These are basically plug-in developer reference info. The kind of stuff you write in your custom plug-in's build.xml to process temporary files etc.
Description
Extend
<ditafileset>
documentation to cover undocumented attributes.Possible Solution
The following attributes are supported by the implementation
@input = true | false
—true
for start document,false
for others; defaults tofalse
@inputResource = true | false
—true
for resources files (--resource
in CLI),false
for others; defaults tofalse
@conref = true | false
—true
for documents that use conref,false
for others; defaults tofalse
@processingRole = resource-only | normal
—resource-only
for documents references as resource only,normal
for normal references; defaults to any.Potential Alternatives
None
Additional Context
Example uses can be found from e.g. build_preprocess_template.xml or build_preprocess2_template.xml.
The text was updated successfully, but these errors were encountered: