> -----Original Message----- > From: Andreas Oberhack [mailto:[EMAIL PROTECTED] > > 1) the xdoc -> checkout -> read / change - > check-in -> inform others > etc. process is to slow and error prone > 2) concurrency is not handled properly or at least difficult
Yes, this method is slower than using a wiki or direct update of the site. However, I'm not sure about error prone or the concurrency issue. There's been a lot more talk on the mailing list about making sure everyone knows about site updates because we're working on a completely new site. Normally the standard SVN updates are sufficient. However, this touches on another point is that we haven't yet setup a publishing mechanism for the new site. The recommended approach is what we had before -- a copy of the generated site in CVS (SVN) and using a cron job to check out the latest site at regular intervals on the webserver. > Beside that we - or maybe only I - have multiple requirements on the > xdoc > -> output generation: > > 1) HTML based output for: our website, eclipse help etc. > 2) Word / PDF output with various layouts: for us / my customers etc. You're not the only one. Maven and Forrest both had built in PDF conversion tools and now that we're using our own XSLT process we need to do something about that. A couple of options: 1. Write our own xdoc -> fo XSL transformations 2. Use maven for PDF transformations (wouldn't be that hard) 3. Use docbook or forrest format for PDF appropriate documents (while I like these formats, I don't recommend we mix and match) I think it would be fairly easy to either use Maven directly or re-use the maven pdf plugin code to create our own xdoc -> fo -> pdf plugin. > My proposals: > > Maybe we could use MoinMoin as the editor for our documentation content. > We get notification, change history, concurrency etc. for free. We could > automatically download the content by RPC and generate the various > output formats by velocity or what ever. Several codehaus.org projects have successfully done this. It's fairly simple. You have a wiki page that specifies the sidebar menu, banner, etc. and then the rest of the pages are your content. You then setup a script which grabs the raw wiki data and apply a template (velocity would work). No one in the ASF has done it yet. I liked the idea [1], but there are some drawbacks. For one, we might need better control over wiki security. Wiki-spam can make this documentation format a mess. Also, you are limited in the complexity of your documents more than you are with the xdoc, forrest, or docbook formats. By using SVN to store the xdoc and generated results we get the same advantages of notification, change history, concurrency and whatnot that you get with a wiki. The only downside I see to this is speed. Using the wiki as your source certainly makes things faster, but doesn't really add any other new features. > I know Niclas, you don't like the limited formatting options in > MoinMoin - but we can easily enhance those if we like. > > What do you all think?? I think there has been a lot of investment in the current xdoc format which is has become fairly standard. As I said before, I like the wiki idea, but there just hasn't been a lot of support for it, especially here at Avalon. I'm interested in getting a better idea of what your frustrations with the existing system are (the one under SVN) outside of PDF generation which we can add. J. Aaron Farr SONY ELECTRONICS STP SYSTEMS (724) 696-7653 http://www.jadetower.org/muses/archives/000051.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
