geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: Geronimo site POC using Confluence & Autoexport
Date Fri, 28 Jul 2006 01:42:09 GMT
I think it would be worthwhile continuing to work on this but I think we 
need to sort out some of the issues mentioned below before we switch 
over so any committer can update the site without requiring assistance 
from Infra or yourself.  I also agree with Matt's comment about it being 
preferable to be able to make changes to the site but not have the 
changes go live instantly.

A bit off topic, do you know of any tools to edit pages offline (where 
you can have a WYSIWYG view of the page) other than installing a 
confluence server on my notebook?


Jason Dillon wrote:
> On Jul 26, 2006, at 8:52 AM, Hernan Cunico wrote:
>> Confluence uses it's own versioning to manage the history changes to 
>> "confluence" pages, AFAIK confluence does not support SVN yet. For 
>> the cwiki we use the "autoexport" plugin to get the confluence 
>> content automatically exported into HTML format and via a template we 
>> customize the look & feel of those exported pages.
> I believe it to be highly unlikely that Confluence will natively 
> support SVN for versioning... ever.  I did however implement a 
> prototype of a plugin that would commit changes to wiki pages to 
> SVN... but never really finished it.
>> The exported pages are independent from confluence version control, 
>> if we use a different version control we will not get the exported 
>> HTML in sync with the actual (and versioned) confluence content. 
>> Rolling back changes will be a nightmare. We need to find out a way 
>> to get those two in sync.
> I believe we can solve this problem easily.  First, when you rollback 
> a page in Confluence, then AutoExport will rebuild the static page 
> based on the new version... so they are in sync in some degree.   For 
> most types of rollbacks the Confluence mechanism should be used.
> Probably we want to include some comments in the generated pages (via 
> the vsl template) to include the path in Confluence, the page version 
> number and who changed it.  Then, if we did rsync to SVN to publish 
> then we have the required details to know how to roll the change back 
> from Confluence.  This should be trivial.
> We could also implement a SVN tag for each push, which would make it 
> easier to quickly rollback the site if something major happened... 
> granted it would be a bit of work to get Confluence back in sync.  
> But, with the above comments, and the tag, we could easily disable the 
> automatic sync and revert pages to the correct version (based on the 
> comments in last known good tag).
> Or, if I finish my SVN plugin, then we could just re-import the entire 
> space from a specific revision number.
> Lots of options.
>> The plugin has some issues/limitations that still need to be 
>> addressed, it even has it's own JIRA 
>> ( Some of those issues will 
>> not let us serve the HTML from a different location, well at least 
>> not totally.
> We may want to add an additional massaging of the content, where we 
> can fix any limitations that AutoExport has...
> Or we could fix AutoExport to better suite our needs.
> Or both.
>> Security seems to be an easy thing to manage as we can restrict 
>> access by users and groups in terms of confluence, but we will not 
>> have access to the actual autoexported HTML content. If we need to 
>> delete any content from the autoexported directories we will not be 
>> able to do it ourselves, just the infrastructure folks have access to 
>> the FS.
> I'm going to see if infra@ will let a few of us have access to it, so 
> that I can better help admin the Confluence install.
> But... the AutoExport plugin should really have a mechanism to clean + 
> publish... which should be easy to add.
> --jason

View raw message