Incremental build scratch pad

This scratch pad for the Incremental builds main page.  Like a Wikipedia discussion tab, this page accumlates notes for the design.

2006-4-29 erikh

Maybe pointing out the obvious, incremental builds of plain-old Java can be managed by comparing the timestamp on the source and compiled file only because the runtime JVM handles the integration.

Unless we have a viewer that can provide equivalent integration at runtime, DITA XML modules have to integrate at build time.  That integration has to resolve:
  • Dependencies created by xrefs, conrefs, and links within the topic
  • Dependencies imposed on a topic by topicrefs in the map (and, looking down the road to DITA 1.2, potentially by key definitions in the map)
These dependencies could probably be represented in Ant syntax using mappers and selectors.  That is, we could generate an Ant file from the DITA map and topics and use that for detecting the need to rebuild (and refresh the snapshot of dependency relationships).

Some potential issues with that approach:
  • The developer has to understand both the DITA and Ant representation of the dependency relationships.
  • We might get more efficiency if the dependency declaration could also store frequently-used text.  For instance, if we store the titles of topics, we don't have to open a topic file to supply its title text to linking topics.
We might still leverage built-in Ant capabilities for timestamp comparison to determine what's changed since the dependency map was last updated.

A final thought - is the dependency map a subset of the merge map?  That is, could the dependency map be the merge map with wireframe (as it were) topics?  That might allow for convergence of tools, processes, and understanding.

Speaking as someone who only uses the ant frontend to DITA-OT (i.e., I don't use the Java API), I'm all for letting ant manage dependencies.  It is, after all, exactly what ant is designed for.

Erik's proposal looks to be in a similar vein to the old "makedepend" thing that was popular in makefiles in the past: have a target which builds a target, which we then include to get the dependencies.  Does anyone remember advantages and disadvantages of the approach?  I'm thinking of read-only volumes messing up one's day, for instance.

We should assemble an exhaustive list of the dependencies that you get with a bare-bones DITA install, and see if they can be factored into categories.  This might suggest whether it's best to let this be managed by XSLT or Java.

Someone also needs to convince me that the incremental build problem and the need to replace dita.list with something "better" are the same problem.
XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I