I'd go for (3). The API you are looking for is org.jbpm.jpdl.xml.JpdlXmlWriter. The problem is, this class is deprecated because there is no real need for it. You might as well build a DOM tree instead of a process definition object.
Here is a first attempt at the algorithm for your program:
For each process definition p:
Look for a node n in the target document whose name matches the name of p
If n does not exist, create it
For each subprocess sp in p:
Look for a node sn in the target document whose name matches the name of sp
If sn does not exist, create it
Create a transition from n to sn
No need for recursion, because you are iterating over all process definitions. If you know the "root" processes beforehand, you can develop a version of this algorithm that probably performs better.
Hope this helps.
and then use an autolayout algorithm (please send it to Koen then as well since he desperately wants one) to have a nice picture
So for approach number 3.
Load the process definitions
Build a unified process definition in memory.
Write the unified process definition to the correct form of XML.
So how do I get the XML format correct for the jpdl builder if I dont use JpdlXmlWriter since its documented as never finished. What classes does the JPDL use to write out the process definition. What would be the starting place for writing out the positioning xml?
I created a little program that stitches all of our process definitions together into a single summary view. The auto layout piece is pretty bad but its not worth the time for us to fix it.
We have one large process with many subprocesses. The document that resulted from the above program drove us to create two unit tests. One unit tests verifies that a subprocess definition exists with the same name as that referred to by each process state. Another test verifies that each flow is referred to by at least one other flow in either an "in" or "out" relationship.
positioning is not done by jbpm, but by the elipse GPD and then GEF, not the GPD itself.