geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Geronimo site POC using Confluence & Autoexport
Date Wed, 26 Jul 2006 19:50:04 GMT

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 (http://could.it/autoexport/ 
> index.html). 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


Mime
View raw message