Cool... cayenne-other probably makes the most sense. I'm working on making it export xdoc-compliant code right now, to let it handle TOC and template generation. So far, the content that is being spit out seems like xdoc will render it well, but will have to wait till its all done to see if the approach is as clean as I'd like.
The content rendering is a little kludgy because Confluence 2.x can't delegate link generation like Confluence 1.x could (since Snipsnap is no longer the rendering engine). We basically either have to reparse the content for link substitution and minor tweaks, or parse the content entirely ourselves. Cris On 4/6/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > Right now internal code that is used to maintain Cayenne build, but > is not itself released, is located under "cayenne-other". So we can > either stick it in "cayenne-other" or create a similar subproject at > the same repository level. > > Andrus > > > > On Apr 6, 2006, at 9:31 PM, Cris Daniluk wrote: > > > The doc generator is coming along, but I'm starting to get a little > > concerned about how to integrate it into Cayenne. It carries a lot > > of weight > > in the form of WSDL and its dependencies - Axis, WSDL4J, blah blah > > blah. I > > figured I would wrap all this in an ant task that was included in the > > cayenne-ant project. Even if I used XML-RPC instead of SOAP, > > though, it > > would bring a lot of baggage in the form of jars. > > > > Should we add a separate project maybe? The only downside to this > > is anyone > > who wants to run "ant release" will need to have it checked out and > > compiled > > to generate the docs. > > > > Cris > >
