geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Geronimo site POC using Confluence & Autoexport
Date Sat, 05 Aug 2006 01:59:28 GMT
Very nice Jason...like Dain asked...is there anything he can do :)

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 
>> (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