The very same idea of using an external tool instead of the export plugin also came to my mind, but I didn't have the time to explore this idea further. I'm +1 for this provided that the following conditions are met:
1. We have volunteers to implement the Confluence solution. That seems to be the case. 2. We can make sure that this solution doesn't cause us troubles with [email protected]. 3. We have no strong proponents of the Markdown solution who would also volunteer to do it with their solution. (If there are volunteers, then we should evaluate more thoroughly the pros and cons of the two solutions) 4. There is no impact on subprojects that want to continue using (Maven) generated sites. Andreas On Fri, Feb 11, 2011 at 13:15, Benson Margulies <[email protected]> wrote: > Currently, the deployed site is a 'forrest' antique. > > We have some pretty reasonable content sitting in Confluence. As you > may know, in general, intrastructure@apache is pushing projects from > Confluence to their new Markdown+svn CMS. The reason is their problems > with the generic export technology used historically with Confluence. > > Some of us are not really thrilled at editing Markdown in a text > editor or web browser. > > Dan Kulp has gone and created an alternative Confluence export device. > It meets the strictures of infrastructure@ and it allows site > maintenance in Confluence. > > I'd like to make ws.apache.org use Confluence (with some maven site > output as appropriate), using Dan's technology. Anybody object? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
