geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <hcun...@gmail.com>
Subject Re: Geronimo site POC using Confluence & Autoexport
Date Wed, 26 Jul 2006 15:52:42 GMT
I think that as a method for generating (not running) the web site HTML, 
confluence is a viable option. I would like to share some considerations 
to keep in mind that I had to deal with when setting up the new cwiki 
and that are equally important for running the web site.

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.

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.

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.

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.

These are just a few considerations, not necessarily issues, we have 
cwiki runnning don't we!?  :)

Cheers!
Hernan

Jason Dillon wrote:
> We can back out with Conluence's versioning for pages.
>
> But if we elect to rsync from the AutoExport dir to SVN and use the 
> normal SVN mechanism to publish then we can do any kind of staging we 
> want.  Disable the automated sync, use the AutoExport URL to 
> test/validate major work, then when its ready to go, run a manual sync 
> and then enable the auto sync... er something like that.
>
> We are free to invent any procedure we need to support our goals for 
> site management and maintenance.
>
> --jason
>
>
> On Jul 25, 2006, at 11:54 AM, Matt Hogstrom wrote:
>
>> Is there anyway to back out changes or make them atomic?  Once nice 
>> thing about the existing process is that people can stage changes and 
>> make them live in an instant.  Perhaps that is not a huge deal but I 
>> prefer not having the site in a state of flux while people are 
>> accessing it.
>>
>>
>> Jason Dillon wrote:
>>> I had been wanting to use Confluence as the primary Geronimo website 
>>> for a while now... and finally just went and created proof of 
>>> concept that it might actually work... check out:
>>>     http://cwiki.apache.org/GMOxSITE/
>>> Looks familiar?  It should, cause its the same layout that we have 
>>> on http://geronimo.apache.org (with a new minor changes).
>>> I have not done much content wise... but I did get all of the side 
>>> navigation pages setup and rendering from "SideNav *" pages (each 
>>> has its own page)... though most of those links point to 
>>> non-existent pages (hence the +).
>>> Looks like there is a still a bit more work that needs to be done to 
>>> refine the autoexpert plugin... like the news links in the "Geronimo 
>>> News" section which are Confluence news pages link you to the 
>>> Confluence page, not the exported page 
>>> (http://cwiki.apache.org/GMOxSITE/2006/07/25/test-news-post.html).
>>> Also some more dynamic stuff, like adding new news does not 
>>> automatically export the pages.  I think this is okay, we can auto 
>>> export on a periodic schedule to get around this limitation... or 
>>> just fix the plugin to be a tad more intelligent.
>>> I've attached the vsl if anyone is interested to see the magic 
>>> needed to get autoexport to do this...
>>>  * * *
>>> Anyways, something to think about... I think its got a lot of 
>>> potential (or I would not still be up at 3am hacking on it) :-)
>>> --jason
>
>


Mime
View raw message