Re: Geronimo site POC using Confluence & Autoexport

[Jeff Turner]

On Wed, Sep 20, 2006 at 09:30:01AM -0400, Hernan Cunico wrote:
> At this point I am kinda confused, so forgive me if we discussed this 
> already.
> Did we ever discussed in getting the autoexported spaces into a local SVN 
> repo on brutus so we then could do an svn up from minotaur (as we do today)?

I don't recall it being discussed. I've just raised it on
[EMAIL PROTECTED]

--Jeff

> Cheers!
> Hernan

>[...]

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

I was going to, but then I got distracted by other things... and  
still unsure I like to hr+ lag that it will take to update a site...  
but I will get over that.


--jason


On Sep 19, 2006, at 10:46 PM, Jeff Turner wrote:


On Tue, Sep 19, 2006 at 03:41:58AM -0700, Jason Dillon wrote:

Did http://people.apache.org/~jefft/confluence/ get moved somewhere
else?


The script broke and I disabled it, thinking no-one used it. I take it
this is being used somehow?

Anyway, I've fixed the script and it's running again.


--Jeff


--jason


On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:


On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:
Okay, I think that the sync that Jeff has setup will allow me to  
move

further on setting up the proof of concept, taking GMOxSITE and
GMOxKB and making them into something suitable to be used for  
http://

geronimo.apache.org


FWIW, http://cwiki.apache.org/ is now being mirrored to
http://people.apache.org/~jefft/confluence/ on every autoexport.
There's
a 'lastupdated' file that can be polled to check for updates.

I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index.
Unfortunately tabs
('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so
I'm not
sure why - needs some investigation.

Discussions are proceeding on infrastructure@ as to how to get
generated
HTML into SVN and thus to the live site. It's painful doing
trailblazing
but the end goal seems worthwhile. I imagine many other projects
will be
interested in this kind of system.


--Jeff


--jason


On Aug 24, 2006, at 3:02 PM, David Blevins wrote:



On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:

Sounds like Jeff Turner may be willing to help us solve this
problem... pending more details.


Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
open sources a stream editing library with the intention of
confluence munging, just Peir beat me to it :)  But doing things
like "munging" urls is a piece of cake:

http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/ 
src/

test/java/org/codehaus/swizzle/stream/
ResolveUrlInputStreamTest.java?r=23

I could crank something out in short order if you give me an idea
of what things need to be updated.

-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:


Assuming you did have access to the box, what steps would be
required to get things setup?  I know I'm asking an unnatural
question as I typically start my thinking while staring at the
command prompt and type commands iteratively till things work.
But I'm just thinking if we could maybe figure that out, we  
could

work with someone who does have access.

I'd also like to use this for GBuild and OpenEJB, so I'm keen on
seeing it solved.

-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:


So, it looks like there is going to need some convincing to get
access to the exported content, so that we can post process and
massage these spaces into our main website.

I'm not even sure that it is going to be worth the effort to  
try

and convince Apache infra that we need the access.  Seems like
they are only willing to give accounts on systems to Apache
members.

So, I wonder if we could just run our own Confluence  
instance on

our zone, only use it to author, then export the content,
massage and then svn ci.  I guess we could also do the same by
moving the spaces to goopen.org too, which will provide us the
required access to implement the site that we all want to
implement.

I'm frustrated... we now have a Confluence instance on ASF, but
we can't really use it to produce the results we want... unless
you want to see http://geronimo.apache.org become a set of
http://cwiki.apache.org* URs... which I find very distasteful.

There might be some way to configure httpd to rewrite urls so
that http://cwiki.apache.org/GMOxSITE looks like http://
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB
looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder
if that is really worth all of the effort.

I guess we could use wget to grab the entire http://
cwiki.apache.org/GMOxSITE and then massage and check in... but
that is terribly inefficient and add more unwanted time lapse
between updating content to making the content live.

So, in short... I can't do anything related to making GMOxSITE
the official website until there is a way to get access to the
exported content, or get the httpd configuration changed for  
our

vhost.

I feel like we have a spiffy new Ferrari that we can only drive
at 5 mph... and as soon as you hit 6 mph it starts to hit  
you on

the head.

:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jeff Turner]

On Wed, Sep 20, 2006 at 09:30:01AM -0400, Hernan Cunico wrote:
> At this point I am kinda confused, so forgive me if we discussed this 
> already.
> Did we ever discussed in getting the autoexported spaces into a local SVN 
> repo on brutus so we then could do an svn up from minotaur (as we do today)?

I don't recall anyone suggesting a SVN repository on brutus be set up.
As I understand it, the plan is to eventually commit generated HTML to
the main Subversion repository. Committing anything to this repo
requires some traceability, hence the talk about CLA groups on
[EMAIL PROTECTED]

I set up the mirror of autoexported HTML at the URL below simply so that
people without brutus access can get involved in setting up the last
"commit to svn" step. It seems Ted (Cc'ed) is most up to date on that
process.


--Jeff

> Cheers!
> Hernan
> 
> Jeff Turner wrote:
> >On Tue, Sep 19, 2006 at 03:41:58AM -0700, Jason Dillon wrote:
> >>Did http://people.apache.org/~jefft/confluence/ get moved somewhere  
> >>else?
> >
> >The script broke and I disabled it, thinking no-one used it. I take it
> >this is being used somehow?
> >
> >Anyway, I've fixed the script and it's running again.
> >
> >
> >--Jeff
> >
> >>--jason
> >>
> >>
> >>On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:
> >>
> >>>On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:
> Okay, I think that the sync that Jeff has setup will allow me to move
> further on setting up the proof of concept, taking GMOxSITE and
> GMOxKB and making them into something suitable to be used for http://
> geronimo.apache.org
> >>>FWIW, http://cwiki.apache.org/ is now being mirrored to
> >>>http://people.apache.org/~jefft/confluence/ on every autoexport.  
> >>>There's
> >>>a 'lastupdated' file that can be polled to check for updates.
> >>>
> >>>I installed the Composition plugin. See test at
> >>>http://cwiki.apache.org/confluence/display/test/Index.  
> >>>Unfortunately tabs
> >>>('cards') don't work on the autoexported HTML at
> >>>http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
> >>>I'm not
> >>>sure why - needs some investigation.
> >>>
> >>>Discussions are proceeding on infrastructure@ as to how to get  
> >>>generated
> >>>HTML into SVN and thus to the live site. It's painful doing  
> >>>trailblazing
> >>>but the end goal seems worthwhile. I imagine many other projects  
> >>>will be
> >>>interested in this kind of system.
> >>>
> >>>
> >>>--Jeff
> >>>
> --jason
> 
> 
> On Aug 24, 2006, at 3:02 PM, David Blevins wrote:
> 
> >On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
> >>Sounds like Jeff Turner may be willing to help us solve this
> >>problem... pending more details.
> >Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
> >open sources a stream editing library with the intention of
> >confluence munging, just Peir beat me to it :)  But doing things
> >like "munging" urls is a piece of cake:
> >
> >http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/
> >test/java/org/codehaus/swizzle/stream/
> >ResolveUrlInputStreamTest.java?r=23
> >
> >I could crank something out in short order if you give me an idea
> >of what things need to be updated.
> >
> >-David
> >
> >>--jason
> >>
> >>
> >>On Aug 23, 2006, at 10:17 PM, David Blevins wrote:
> >>
> >>>Assuming you did have access to the box, what steps would be
> >>>required to get things setup?  I know I'm asking an unnatural
> >>>question as I typically start my thinking while staring at the
> >>>command prompt and type commands iteratively till things work.
> >>>But I'm just thinking if we could maybe figure that out, we could
> >>>work with someone who does have access.
> >>>
> >>>I'd also like to use this for GBuild and OpenEJB, so I'm keen on
> >>>seeing it solved.
> >>>
> >>>-David
> >>>
> >>>On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:
> >>>
> So, it looks like there is going to need some convincing to get
> access to the exported content, so that we can post process and
> massage these spaces into our main website.
> 
> I'm not even sure that it is going to be worth the effort to try
> and convince Apache infra that we need the access.  Seems like
> they are only willing to give accounts on systems to Apache
> members.
> 
> So, I wonder if we could just run our own Confluence instance on
> our zone, only use it to author, then export the content,
> massage and then svn ci.  I guess we could also do the same by
> moving the spaces to goopen.org too, which will provide us the
> required access to implement the site that we all want to
> implement.
> 
> I'm frustrated... we now have a Confluence instance on ASF, but
> we can't really use it

Re: Geronimo site POC using Confluence & Autoexport

[Hernan Cunico]

At this point I am kinda confused, so forgive me if we discussed this already.
Did we ever discussed in getting the autoexported spaces into a local SVN repo 
on brutus so we then could do an svn up from minotaur (as we do today)?

Cheers!
Hernan

Jeff Turner wrote:

On Tue, Sep 19, 2006 at 03:41:58AM -0700, Jason Dillon wrote:
Did http://people.apache.org/~jefft/confluence/ get moved somewhere  
else?


The script broke and I disabled it, thinking no-one used it. I take it
this is being used somehow?

Anyway, I've fixed the script and it's running again.


--Jeff


--jason


On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:


On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:

Okay, I think that the sync that Jeff has setup will allow me to move
further on setting up the proof of concept, taking GMOxSITE and
GMOxKB and making them into something suitable to be used for http://
geronimo.apache.org

FWIW, http://cwiki.apache.org/ is now being mirrored to
http://people.apache.org/~jefft/confluence/ on every autoexport.  
There's

a 'lastupdated' file that can be polled to check for updates.

I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index.  
Unfortunately tabs

('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
I'm not

sure why - needs some investigation.

Discussions are proceeding on infrastructure@ as to how to get  
generated
HTML into SVN and thus to the live site. It's painful doing  
trailblazing
but the end goal seems worthwhile. I imagine many other projects  
will be

interested in this kind of system.


--Jeff


--jason


On Aug 24, 2006, at 3:02 PM, David Blevins wrote:


On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:

Sounds like Jeff Turner may be willing to help us solve this
problem... pending more details.

Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
open sources a stream editing library with the intention of
confluence munging, just Peir beat me to it :)  But doing things
like "munging" urls is a piece of cake:

http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/
test/java/org/codehaus/swizzle/stream/
ResolveUrlInputStreamTest.java?r=23

I could crank something out in short order if you give me an idea
of what things need to be updated.

-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:


Assuming you did have access to the box, what steps would be
required to get things setup?  I know I'm asking an unnatural
question as I typically start my thinking while staring at the
command prompt and type commands iteratively till things work.
But I'm just thinking if we could maybe figure that out, we could
work with someone who does have access.

I'd also like to use this for GBuild and OpenEJB, so I'm keen on
seeing it solved.

-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:


So, it looks like there is going to need some convincing to get
access to the exported content, so that we can post process and
massage these spaces into our main website.

I'm not even sure that it is going to be worth the effort to try
and convince Apache infra that we need the access.  Seems like
they are only willing to give accounts on systems to Apache
members.

So, I wonder if we could just run our own Confluence instance on
our zone, only use it to author, then export the content,
massage and then svn ci.  I guess we could also do the same by
moving the spaces to goopen.org too, which will provide us the
required access to implement the site that we all want to
implement.

I'm frustrated... we now have a Confluence instance on ASF, but
we can't really use it to produce the results we want... unless
you want to see http://geronimo.apache.org become a set of
http://cwiki.apache.org* URs... which I find very distasteful.

There might be some way to configure httpd to rewrite urls so
that http://cwiki.apache.org/GMOxSITE looks like http://
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB
looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder
if that is really worth all of the effort.

I guess we could use wget to grab the entire http://
cwiki.apache.org/GMOxSITE and then massage and check in... but
that is terribly inefficient and add more unwanted time lapse
between updating content to making the content live.

So, in short... I can't do anything related to making GMOxSITE
the official website until there is a way to get access to the
exported content, or get the httpd configuration changed for our
vhost.

I feel like we have a spiffy new Ferrari that we can only drive
at 5 mph... and as soon as you hit 6 mph it starts to hit you on
the head.

:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jeff Turner]

On Tue, Sep 19, 2006 at 03:41:58AM -0700, Jason Dillon wrote:
> Did http://people.apache.org/~jefft/confluence/ get moved somewhere  
> else?

The script broke and I disabled it, thinking no-one used it. I take it
this is being used somehow?

Anyway, I've fixed the script and it's running again.


--Jeff

> --jason
> 
> 
> On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:
> 
> >On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:
> >>Okay, I think that the sync that Jeff has setup will allow me to move
> >>further on setting up the proof of concept, taking GMOxSITE and
> >>GMOxKB and making them into something suitable to be used for http://
> >>geronimo.apache.org
> >
> >FWIW, http://cwiki.apache.org/ is now being mirrored to
> >http://people.apache.org/~jefft/confluence/ on every autoexport.  
> >There's
> >a 'lastupdated' file that can be polled to check for updates.
> >
> >I installed the Composition plugin. See test at
> >http://cwiki.apache.org/confluence/display/test/Index.  
> >Unfortunately tabs
> >('cards') don't work on the autoexported HTML at
> >http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
> >I'm not
> >sure why - needs some investigation.
> >
> >Discussions are proceeding on infrastructure@ as to how to get  
> >generated
> >HTML into SVN and thus to the live site. It's painful doing  
> >trailblazing
> >but the end goal seems worthwhile. I imagine many other projects  
> >will be
> >interested in this kind of system.
> >
> >
> >--Jeff
> >
> >>--jason
> >>
> >>
> >>On Aug 24, 2006, at 3:02 PM, David Blevins wrote:
> >>
> >>>
> >>>On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
> Sounds like Jeff Turner may be willing to help us solve this
> problem... pending more details.
> >>>
> >>>Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
> >>>open sources a stream editing library with the intention of
> >>>confluence munging, just Peir beat me to it :)  But doing things
> >>>like "munging" urls is a piece of cake:
> >>>
> >>>http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/
> >>>test/java/org/codehaus/swizzle/stream/
> >>>ResolveUrlInputStreamTest.java?r=23
> >>>
> >>>I could crank something out in short order if you give me an idea
> >>>of what things need to be updated.
> >>>
> >>>-David
> >>>
> --jason
> 
> 
> On Aug 23, 2006, at 10:17 PM, David Blevins wrote:
> 
> >Assuming you did have access to the box, what steps would be
> >required to get things setup?  I know I'm asking an unnatural
> >question as I typically start my thinking while staring at the
> >command prompt and type commands iteratively till things work.
> >But I'm just thinking if we could maybe figure that out, we could
> >work with someone who does have access.
> >
> >I'd also like to use this for GBuild and OpenEJB, so I'm keen on
> >seeing it solved.
> >
> >-David
> >
> >On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:
> >
> >>So, it looks like there is going to need some convincing to get
> >>access to the exported content, so that we can post process and
> >>massage these spaces into our main website.
> >>
> >>I'm not even sure that it is going to be worth the effort to try
> >>and convince Apache infra that we need the access.  Seems like
> >>they are only willing to give accounts on systems to Apache
> >>members.
> >>
> >>So, I wonder if we could just run our own Confluence instance on
> >>our zone, only use it to author, then export the content,
> >>massage and then svn ci.  I guess we could also do the same by
> >>moving the spaces to goopen.org too, which will provide us the
> >>required access to implement the site that we all want to
> >>implement.
> >>
> >>I'm frustrated... we now have a Confluence instance on ASF, but
> >>we can't really use it to produce the results we want... unless
> >>you want to see http://geronimo.apache.org become a set of
> >>http://cwiki.apache.org* URs... which I find very distasteful.
> >>
> >>There might be some way to configure httpd to rewrite urls so
> >>that http://cwiki.apache.org/GMOxSITE looks like http://
> >>geronimo.apache.org and that http://cwiki.apache.org/GMOxKB
> >>looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder
> >>if that is really worth all of the effort.
> >>
> >>I guess we could use wget to grab the entire http://
> >>cwiki.apache.org/GMOxSITE and then massage and check in... but
> >>that is terribly inefficient and add more unwanted time lapse
> >>between updating content to making the content live.
> >>
> >>So, in short... I can't do anything related to making GMOxSITE
> >>the official website until there is a way to get access to the
> >>exported content, or get the httpd configuration changed for our
> >>vhost.
> >>
> >>I feel like we have a spiffy 

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

Did http://people.apache.org/~jefft/confluence/ get moved somewhere  
else?


--jason


On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:


On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:

Okay, I think that the sync that Jeff has setup will allow me to move
further on setting up the proof of concept, taking GMOxSITE and
GMOxKB and making them into something suitable to be used for http://
geronimo.apache.org


FWIW, http://cwiki.apache.org/ is now being mirrored to
http://people.apache.org/~jefft/confluence/ on every autoexport.  
There's

a 'lastupdated' file that can be polled to check for updates.

I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index.  
Unfortunately tabs

('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
I'm not

sure why - needs some investigation.

Discussions are proceeding on infrastructure@ as to how to get  
generated
HTML into SVN and thus to the live site. It's painful doing  
trailblazing
but the end goal seems worthwhile. I imagine many other projects  
will be

interested in this kind of system.


--Jeff


--jason


On Aug 24, 2006, at 3:02 PM, David Blevins wrote:



On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:

Sounds like Jeff Turner may be willing to help us solve this
problem... pending more details.


Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
open sources a stream editing library with the intention of
confluence munging, just Peir beat me to it :)  But doing things
like "munging" urls is a piece of cake:

http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/
test/java/org/codehaus/swizzle/stream/
ResolveUrlInputStreamTest.java?r=23

I could crank something out in short order if you give me an idea
of what things need to be updated.

-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:


Assuming you did have access to the box, what steps would be
required to get things setup?  I know I'm asking an unnatural
question as I typically start my thinking while staring at the
command prompt and type commands iteratively till things work.
But I'm just thinking if we could maybe figure that out, we could
work with someone who does have access.

I'd also like to use this for GBuild and OpenEJB, so I'm keen on
seeing it solved.

-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:


So, it looks like there is going to need some convincing to get
access to the exported content, so that we can post process and
massage these spaces into our main website.

I'm not even sure that it is going to be worth the effort to try
and convince Apache infra that we need the access.  Seems like
they are only willing to give accounts on systems to Apache
members.

So, I wonder if we could just run our own Confluence instance on
our zone, only use it to author, then export the content,
massage and then svn ci.  I guess we could also do the same by
moving the spaces to goopen.org too, which will provide us the
required access to implement the site that we all want to
implement.

I'm frustrated... we now have a Confluence instance on ASF, but
we can't really use it to produce the results we want... unless
you want to see http://geronimo.apache.org become a set of
http://cwiki.apache.org* URs... which I find very distasteful.

There might be some way to configure httpd to rewrite urls so
that http://cwiki.apache.org/GMOxSITE looks like http://
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB
looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder
if that is really worth all of the effort.

I guess we could use wget to grab the entire http://
cwiki.apache.org/GMOxSITE and then massage and check in... but
that is terribly inefficient and add more unwanted time lapse
between updating content to making the content live.

So, in short... I can't do anything related to making GMOxSITE
the official website until there is a way to get access to the
exported content, or get the httpd configuration changed for our
vhost.

I feel like we have a spiffy new Ferrari that we can only drive
at 5 mph... and as soon as you hit 6 mph it starts to hit you on
the head.

:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

After a bunch of hacking and blind stylesheeting, I've gotten the  
composition macro to be usable on exported content... tabs at least,  
did not try cloaked sections.


I need to clean this up but look for new goodies on the next rev  
of the POC site :-)


--jason


On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:


On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:

Okay, I think that the sync that Jeff has setup will allow me to move
further on setting up the proof of concept, taking GMOxSITE and
GMOxKB and making them into something suitable to be used for http://
geronimo.apache.org


FWIW, http://cwiki.apache.org/ is now being mirrored to
http://people.apache.org/~jefft/confluence/ on every autoexport.  
There's

a 'lastupdated' file that can be polled to check for updates.

I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index.  
Unfortunately tabs

('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
I'm not

sure why - needs some investigation.

Discussions are proceeding on infrastructure@ as to how to get  
generated
HTML into SVN and thus to the live site. It's painful doing  
trailblazing
but the end goal seems worthwhile. I imagine many other projects  
will be

interested in this kind of system.


--Jeff


--jason


On Aug 24, 2006, at 3:02 PM, David Blevins wrote:



On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:

Sounds like Jeff Turner may be willing to help us solve this
problem... pending more details.


Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I
open sources a stream editing library with the intention of
confluence munging, just Peir beat me to it :)  But doing things
like "munging" urls is a piece of cake:

http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/
test/java/org/codehaus/swizzle/stream/
ResolveUrlInputStreamTest.java?r=23

I could crank something out in short order if you give me an idea
of what things need to be updated.

-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:


Assuming you did have access to the box, what steps would be
required to get things setup?  I know I'm asking an unnatural
question as I typically start my thinking while staring at the
command prompt and type commands iteratively till things work.
But I'm just thinking if we could maybe figure that out, we could
work with someone who does have access.

I'd also like to use this for GBuild and OpenEJB, so I'm keen on
seeing it solved.

-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:


So, it looks like there is going to need some convincing to get
access to the exported content, so that we can post process and
massage these spaces into our main website.

I'm not even sure that it is going to be worth the effort to try
and convince Apache infra that we need the access.  Seems like
they are only willing to give accounts on systems to Apache
members.

So, I wonder if we could just run our own Confluence instance on
our zone, only use it to author, then export the content,
massage and then svn ci.  I guess we could also do the same by
moving the spaces to goopen.org too, which will provide us the
required access to implement the site that we all want to
implement.

I'm frustrated... we now have a Confluence instance on ASF, but
we can't really use it to produce the results we want... unless
you want to see http://geronimo.apache.org become a set of
http://cwiki.apache.org* URs... which I find very distasteful.

There might be some way to configure httpd to rewrite urls so
that http://cwiki.apache.org/GMOxSITE looks like http://
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB
looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder
if that is really worth all of the effort.

I guess we could use wget to grab the entire http://
cwiki.apache.org/GMOxSITE and then massage and check in... but
that is terribly inefficient and add more unwanted time lapse
between updating content to making the content live.

So, in short... I can't do anything related to making GMOxSITE
the official website until there is a way to get access to the
exported content, or get the httpd configuration changed for our
vhost.

I feel like we have a spiffy new Ferrari that we can only drive
at 5 mph... and as soon as you hit 6 mph it starts to hit you on
the head.

:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Dain Sundstrom]

On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:


I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index.  
Unfortunately tabs

('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
I'm not

sure why - needs some investigation.


That is super cool and exactly what I needed the other day.  I was  
writing some docs for xbean-spring and wanted to show a few different  
styles of configuration for the same example.  Stacking the examples  
would have been a much better layout.  Instead I ended up with a very  
long page.


Discussions are proceeding on infrastructure@ as to how to get  
generated
HTML into SVN and thus to the live site. It's painful doing  
trailblazing
but the end goal seems worthwhile. I imagine many other projects  
will be

interested in this kind of system.


Thanks for all the help Jeff.

-dain

Re: Geronimo site POC using Confluence & Autoexport

[Jeff Turner]

On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:
> Okay, I think that the sync that Jeff has setup will allow me to move  
> further on setting up the proof of concept, taking GMOxSITE and  
> GMOxKB and making them into something suitable to be used for http:// 
> geronimo.apache.org

FWIW, http://cwiki.apache.org/ is now being mirrored to
http://people.apache.org/~jefft/confluence/ on every autoexport. There's
a 'lastupdated' file that can be polled to check for updates.

I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index. Unfortunately tabs
('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so I'm not
sure why - needs some investigation.

Discussions are proceeding on infrastructure@ as to how to get generated
HTML into SVN and thus to the live site. It's painful doing trailblazing
but the end goal seems worthwhile. I imagine many other projects will be
interested in this kind of system.


--Jeff

> --jason
> 
> 
> On Aug 24, 2006, at 3:02 PM, David Blevins wrote:
> 
> >
> > On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
> >> Sounds like Jeff Turner may be willing to help us solve this  
> >> problem... pending more details.
> >
> > Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I  
> > open sources a stream editing library with the intention of  
> > confluence munging, just Peir beat me to it :)  But doing things  
> > like "munging" urls is a piece of cake:
> >
> > http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/ 
> > test/java/org/codehaus/swizzle/stream/ 
> > ResolveUrlInputStreamTest.java?r=23
> >
> > I could crank something out in short order if you give me an idea  
> > of what things need to be updated.
> >
> > -David
> >
> >> --jason
> >>
> >>
> >> On Aug 23, 2006, at 10:17 PM, David Blevins wrote:
> >>
> >>> Assuming you did have access to the box, what steps would be  
> >>> required to get things setup?  I know I'm asking an unnatural  
> >>> question as I typically start my thinking while staring at the  
> >>> command prompt and type commands iteratively till things work.   
> >>> But I'm just thinking if we could maybe figure that out, we could  
> >>> work with someone who does have access.
> >>>
> >>> I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
> >>> seeing it solved.
> >>>
> >>> -David
> >>>
> >>> On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:
> >>>
>  So, it looks like there is going to need some convincing to get  
>  access to the exported content, so that we can post process and  
>  massage these spaces into our main website.
> 
>  I'm not even sure that it is going to be worth the effort to try  
>  and convince Apache infra that we need the access.  Seems like  
>  they are only willing to give accounts on systems to Apache  
>  members.
> 
>  So, I wonder if we could just run our own Confluence instance on  
>  our zone, only use it to author, then export the content,  
>  massage and then svn ci.  I guess we could also do the same by  
>  moving the spaces to goopen.org too, which will provide us the  
>  required access to implement the site that we all want to  
>  implement.
> 
>  I'm frustrated... we now have a Confluence instance on ASF, but  
>  we can't really use it to produce the results we want... unless  
>  you want to see http://geronimo.apache.org become a set of  
>  http://cwiki.apache.org* URs... which I find very distasteful.
> 
>  There might be some way to configure httpd to rewrite urls so  
>  that http://cwiki.apache.org/GMOxSITE looks like http:// 
>  geronimo.apache.org and that http://cwiki.apache.org/GMOxKB  
>  looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder  
>  if that is really worth all of the effort.
> 
>  I guess we could use wget to grab the entire http:// 
>  cwiki.apache.org/GMOxSITE and then massage and check in... but  
>  that is terribly inefficient and add more unwanted time lapse  
>  between updating content to making the content live.
> 
>  So, in short... I can't do anything related to making GMOxSITE  
>  the official website until there is a way to get access to the  
>  exported content, or get the httpd configuration changed for our  
>  vhost.
> 
>  I feel like we have a spiffy new Ferrari that we can only drive  
>  at 5 mph... and as soon as you hit 6 mph it starts to hit you on  
>  the head.
> 
>  :-(
> 
>  --jason
> 
> >>>
> >>
> >

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

Okay, I think that the sync that Jeff has setup will allow me to move  
further on setting up the proof of concept, taking GMOxSITE and  
GMOxKB and making them into something suitable to be used for http:// 
geronimo.apache.org


--jason


On Aug 24, 2006, at 3:02 PM, David Blevins wrote:



On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
Sounds like Jeff Turner may be willing to help us solve this  
problem... pending more details.


Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I  
open sources a stream editing library with the intention of  
confluence munging, just Peir beat me to it :)  But doing things  
like "munging" urls is a piece of cake:


http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/ 
test/java/org/codehaus/swizzle/stream/ 
ResolveUrlInputStreamTest.java?r=23


I could crank something out in short order if you give me an idea  
of what things need to be updated.


-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:

Assuming you did have access to the box, what steps would be  
required to get things setup?  I know I'm asking an unnatural  
question as I typically start my thinking while staring at the  
command prompt and type commands iteratively till things work.   
But I'm just thinking if we could maybe figure that out, we could  
work with someone who does have access.


I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
seeing it solved.


-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try  
and convince Apache infra that we need the access.  Seems like  
they are only willing to give accounts on systems to Apache  
members.


So, I wonder if we could just run our own Confluence instance on  
our zone, only use it to author, then export the content,  
massage and then svn ci.  I guess we could also do the same by  
moving the spaces to goopen.org too, which will provide us the  
required access to implement the site that we all want to  
implement.


I'm frustrated... we now have a Confluence instance on ASF, but  
we can't really use it to produce the results we want... unless  
you want to see http://geronimo.apache.org become a set of  
http://cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so  
that http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB  
looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder  
if that is really worth all of the effort.


I guess we could use wget to grab the entire http:// 
cwiki.apache.org/GMOxSITE and then massage and check in... but  
that is terribly inefficient and add more unwanted time lapse  
between updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE  
the official website until there is a way to get access to the  
exported content, or get the httpd configuration changed for our  
vhost.


I feel like we have a spiffy new Ferrari that we can only drive  
at 5 mph... and as soon as you hit 6 mph it starts to hit you on  
the head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[David Blevins]

On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
Sounds like Jeff Turner may be willing to help us solve this  
problem... pending more details.


Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I  
open sources a stream editing library with the intention of  
confluence munging, just Peir beat me to it :)  But doing things like  
"munging" urls is a piece of cake:


http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/ 
test/java/org/codehaus/swizzle/stream/ResolveUrlInputStreamTest.java? 
r=23


I could crank something out in short order if you give me an idea of  
what things need to be updated.


-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:

Assuming you did have access to the box, what steps would be  
required to get things setup?  I know I'm asking an unnatural  
question as I typically start my thinking while staring at the  
command prompt and type commands iteratively till things work.   
But I'm just thinking if we could maybe figure that out, we could  
work with someone who does have access.


I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
seeing it solved.


-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try  
and convince Apache infra that we need the access.  Seems like  
they are only willing to give accounts on systems to Apache members.


So, I wonder if we could just run our own Confluence instance on  
our zone, only use it to author, then export the content, massage  
and then svn ci.  I guess we could also do the same by moving the  
spaces to goopen.org too, which will provide us the required  
access to implement the site that we all want to implement.


I'm frustrated... we now have a Confluence instance on ASF, but  
we can't really use it to produce the results we want... unless  
you want to see http://geronimo.apache.org become a set of http:// 
cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so  
that http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB looks  
like http://cwiki.apache.org/GMOxKB, etc... but I wonder if that  
is really worth all of the effort.


I guess we could use wget to grab the entire http:// 
cwiki.apache.org/GMOxSITE and then massage and check in... but  
that is terribly inefficient and add more unwanted time lapse  
between updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE  
the official website until there is a way to get access to the  
exported content, or get the httpd configuration changed for our  
vhost.


I feel like we have a spiffy new Ferrari that we can only drive  
at 5 mph... and as soon as you hit 6 mph it starts to hit you on  
the head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

So, I think all that is needed is a little cleansing of the exported  
HTML to get around some issues with the AE plugin.  And then an rsync  
and svn magic to resolve whats removed, whats added and changed & ci  
then svn up people:/www/*.  Assuming that we still want this in SVN.   
Else, the rsync could just update /www/* directly.


Sounds like Jeff Turner may be willing to help us solve this  
problem... pending more details.


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:

Assuming you did have access to the box, what steps would be  
required to get things setup?  I know I'm asking an unnatural  
question as I typically start my thinking while staring at the  
command prompt and type commands iteratively till things work.  But  
I'm just thinking if we could maybe figure that out, we could work  
with someone who does have access.


I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
seeing it solved.


-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try  
and convince Apache infra that we need the access.  Seems like  
they are only willing to give accounts on systems to Apache members.


So, I wonder if we could just run our own Confluence instance on  
our zone, only use it to author, then export the content, massage  
and then svn ci.  I guess we could also do the same by moving the  
spaces to goopen.org too, which will provide us the required  
access to implement the site that we all want to implement.


I'm frustrated... we now have a Confluence instance on ASF, but we  
can't really use it to produce the results we want... unless you  
want to see http://geronimo.apache.org become a set of http:// 
cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so that  
http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB looks  
like http://cwiki.apache.org/GMOxKB, etc... but I wonder if that  
is really worth all of the effort.


I guess we could use wget to grab the entire http:// 
cwiki.apache.org/GMOxSITE and then massage and check in... but  
that is terribly inefficient and add more unwanted time lapse  
between updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE the  
official website until there is a way to get access to the  
exported content, or get the httpd configuration changed for our  
vhost.


I feel like we have a spiffy new Ferrari that we can only drive at  
5 mph... and as soon as you hit 6 mph it starts to hit you on the  
head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Hernan Cunico]

Dain Sundstrom wrote:

On Aug 24, 2006, at 7:41 AM, Hernan Cunico wrote:

anyway, web site authoring aside, what are the benefits of moving all 
the cwiki content, just a change in the URL? what is the issue if we 
have pointers back and forth on both sites?


Um what do you mean by "moving all the cwiki content"?


I thought I saw a trend for moving content over the main web site (KB, 
maven, ...). Anyway, just my perception.


Anyway, we use cwiki to edit our main site, the internal URLs need to 
point to geronimo.apache.org or all of our web traffic will end up on 
the cwiki server and infra will be very upset.


Yup, but we are not discussing where to host the web site. As I said in 
the previous note, "... I think that the effort of authoring the web 
site ( just the web site ) is worth pursuing ..."




Just as an example, we initially had the FAQ on the web site (well, 
had others in the old wiki and spread out throughout the 
documentation), then we created a KB space in confluence and 
consolidated all FAQ into that space. Why take it back to 
geronimo.apache.org/KB? In the web site there is a link on every 
single page pointing directly to the KB in the cwiki.


IMO, it would be best if we exported the KB space and rewrote the 
internal urls to be within geronimo.apache.org.  This would keep the KB 
traffic on the main apache server.


Do we know how much traffic we have over the KB space now, both view and 
edit?


I don't really see the benefit of moving the space into the main site, I 
think it is more a personal preference than any other thing, I'm cool 
with that.


The way I (personally) see it is that we develop the content on 
Confluence and we have it autoexported there. We point to it from every 
single page on the main web site, so my question is why should we move 
it? The only thing I see is a change in the URL




Back to the web site authoring, let's assume we have access to the 
file system. We would have to copy all the autoexported HTML somewhere 
else, fix all the links and images ( the autoexport plugin has some 
"issues" ) and then put it into the svn repository. Once there, we all 
know the procedure to get it published. One thing to keep in mind is 
that we would not have the site's source versioned in svn, rolling 
back from backup may not be an easy tasks.


If we can get cwiki to check the existing content into svn, we can use 
the following steps:


1) cwiki: write static html
2) cwiki: svn commit changes to 
https://svn.apache.org/repos/asf/geronimo/site/cwiki

2) zone*: svn update https://svn.apache.org/repos/asf/geronimo/site
3) zone: rewrite cwiki urls
4) zone: svn commit changes to 
http://svn.apache.org/repos/asf/geronimo/site/trunk/docs

5) www: svn update http://svn.apache.org/repos/asf/geronimo/site/trunk/docs

This is basically what goopen does to create the xbean site. Except the 
first 5 steps all happen on the goopen server.


* zone is our apache geronimo zone server


see the "Access to cwiki filesystem" thread on infra.



I think that the effort of authoring the web site ( just the web site 
) is worth pursuing and I'm more than willing to contribute to find a 
more elegant solution for developing the web site.


It would be great if we can all agree on what content belongs to the 
wiki and what content belongs to the web site ( dynamic vs. static ).


If we have the system above, there is no need to make this type of 
distinction anymore, and we will be able to use powerful tools like 
snippit on our main site (see 
http://geronimo.apache.org/xbean/editing-custom-xml.html)


Note sure I follow, we would still have the main site and the cwiki. My 
point was for us to determine what content is static enough to go 
directly into the web site and what content is not along with the 
ability to promptly edit any content.


Is there any other space, other than KB and obviously SITE, that we 
would like to serve directly from the main site?


Cheers!
Hernan



-dain

Re: Geronimo site POC using Confluence & Autoexport

[Dain Sundstrom]

On Aug 24, 2006, at 7:41 AM, Hernan Cunico wrote:

anyway, web site authoring aside, what are the benefits of moving  
all the cwiki content, just a change in the URL? what is the issue  
if we have pointers back and forth on both sites?


Um what do you mean by "moving all the cwiki content"?

Anyway, we use cwiki to edit our main site, the internal URLs need to  
point to geronimo.apache.org or all of our web traffic will end up on  
the cwiki server and infra will be very upset.


Just as an example, we initially had the FAQ on the web site (well,  
had others in the old wiki and spread out throughout the  
documentation), then we created a KB space in confluence and  
consolidated all FAQ into that space. Why take it back to  
geronimo.apache.org/KB? In the web site there is a link on every  
single page pointing directly to the KB in the cwiki.


IMO, it would be best if we exported the KB space and rewrote the  
internal urls to be within geronimo.apache.org.  This would keep the  
KB traffic on the main apache server.


Back to the web site authoring, let's assume we have access to the  
file system. We would have to copy all the autoexported HTML  
somewhere else, fix all the links and images ( the autoexport  
plugin has some "issues" ) and then put it into the svn repository.  
Once there, we all know the procedure to get it published. One  
thing to keep in mind is that we would not have the site's source  
versioned in svn, rolling back from backup may not be an easy tasks.


If we can get cwiki to check the existing content into svn, we can  
use the following steps:


1) cwiki: write static html
2) cwiki: svn commit changes to https://svn.apache.org/repos/asf/ 
geronimo/site/cwiki

2) zone*: svn update https://svn.apache.org/repos/asf/geronimo/site
3) zone: rewrite cwiki urls
4) zone: svn commit changes to http://svn.apache.org/repos/asf/ 
geronimo/site/trunk/docs
5) www: svn update http://svn.apache.org/repos/asf/geronimo/site/ 
trunk/docs


This is basically what goopen does to create the xbean site. Except  
the first 5 steps all happen on the goopen server.


* zone is our apache geronimo zone server

I think that the effort of authoring the web site ( just the web  
site ) is worth pursuing and I'm more than willing to contribute to  
find a more elegant solution for developing the web site.


It would be great if we can all agree on what content belongs to  
the wiki and what content belongs to the web site ( dynamic vs.  
static ).


If we have the system above, there is no need to make this type of  
distinction anymore, and we will be able to use powerful tools like  
snippit on our main site (see http://geronimo.apache.org/xbean/ 
editing-custom-xml.html)


-dain

Re: Geronimo site POC using Confluence & Autoexport

[Hernan Cunico]

It took us a humongous effort and time to get Confluence to run within 
the ASF so we can now have the "cwiki".


Confluence is great and we continue to find more cool features, but the 
main goal of the cwiki is to be a "wiki" itself, we use it to document 
the project.


First it was just the documentation, then we added more stuffs like the 
FAQ ( aka GMOxKB ), now we plan to develop the project's web site 
directly in Confluence. So far so  good, Confluence is great for 
collaboration and we can add templates and make the autoexported HTML 
look even cooler.


I grant that authoring the Web site in Confluence, get it exported to 
HTML and served from geronimo.apache.com might be better to what we have 
today but I definitively do not agree in moving everything we have 
exported as static HTML in Confluence to the main geronimo.apache.org site.


I disagree even more in trying to use an external to the ASF Confluence 
installation to generate static HTML and then put it back into the main 
site. (Going outside the ASF every time we can't get the things the way 
we want should be a separate thread)


anyway, web site authoring aside, what are the benefits of moving all 
the cwiki content, just a change in the URL? what is the issue if we 
have pointers back and forth on both sites?


Just as an example, we initially had the FAQ on the web site (well, had 
others in the old wiki and spread out throughout the documentation), 
then we created a KB space in confluence and consolidated all FAQ into 
that space. Why take it back to geronimo.apache.org/KB? In the web site 
there is a link on every single page pointing directly to the KB in the 
cwiki.


Back to the web site authoring, let's assume we have access to the file 
system. We would have to copy all the autoexported HTML somewhere else, 
fix all the links and images ( the autoexport plugin has some "issues" ) 
and then put it into the svn repository. Once there, we all know the 
procedure to get it published. One thing to keep in mind is that we 
would not have the site's source versioned in svn, rolling back from 
backup may not be an easy tasks.


I think that the effort of authoring the web site ( just the web site ) 
is worth pursuing and I'm more than willing to contribute to find a more 
elegant solution for developing the web site.


It would be great if we can all agree on what content belongs to the 
wiki and what content belongs to the web site ( dynamic vs. static ).


Cheers!
Hernan

Jason Dillon wrote:
So, it looks like there is going to need some convincing to get access 
to the exported content, so that we can post process and massage these 
spaces into our main website.


I'm not even sure that it is going to be worth the effort to try and 
convince Apache infra that we need the access.  Seems like they are only 
willing to give accounts on systems to Apache members.


So, I wonder if we could just run our own Confluence instance on our 
zone, only use it to author, then export the content, massage and then 
svn ci.  I guess we could also do the same by moving the spaces to 
goopen.org too, which will provide us the required access to implement 
the site that we all want to implement.


I'm frustrated... we now have a Confluence instance on ASF, but we can't 
really use it to produce the results we want... unless you want to see 
http://geronimo.apache.org become a set of http://cwiki.apache.org* 
URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so that 
http://cwiki.apache.org/GMOxSITE looks like http://geronimo.apache.org 
and that http://cwiki.apache.org/GMOxKB looks like 
http://cwiki.apache.org/GMOxKB, etc... but I wonder if that is really 
worth all of the effort.


I guess we could use wget to grab the entire 
http://cwiki.apache.org/GMOxSITE and then massage and check in... but 
that is terribly inefficient and add more unwanted time lapse between 
updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE the 
official website until there is a way to get access to the exported 
content, or get the httpd configuration changed for our vhost.


I feel like we have a spiffy new Ferrari that we can only drive at 5 
mph... and as soon as you hit 6 mph it starts to hit you on the head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

I think we'd have to wget the site and the massage it.

--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:

Assuming you did have access to the box, what steps would be  
required to get things setup?  I know I'm asking an unnatural  
question as I typically start my thinking while staring at the  
command prompt and type commands iteratively till things work.  But  
I'm just thinking if we could maybe figure that out, we could work  
with someone who does have access.


I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
seeing it solved.


-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try  
and convince Apache infra that we need the access.  Seems like  
they are only willing to give accounts on systems to Apache members.


So, I wonder if we could just run our own Confluence instance on  
our zone, only use it to author, then export the content, massage  
and then svn ci.  I guess we could also do the same by moving the  
spaces to goopen.org too, which will provide us the required  
access to implement the site that we all want to implement.


I'm frustrated... we now have a Confluence instance on ASF, but we  
can't really use it to produce the results we want... unless you  
want to see http://geronimo.apache.org become a set of http:// 
cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so that  
http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB looks  
like http://cwiki.apache.org/GMOxKB, etc... but I wonder if that  
is really worth all of the effort.


I guess we could use wget to grab the entire http:// 
cwiki.apache.org/GMOxSITE and then massage and check in... but  
that is terribly inefficient and add more unwanted time lapse  
between updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE the  
official website until there is a way to get access to the  
exported content, or get the httpd configuration changed for our  
vhost.


I feel like we have a spiffy new Ferrari that we can only drive at  
5 mph... and as soon as you hit 6 mph it starts to hit you on the  
head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[David Blevins]

Assuming you did have access to the box, what steps would be required  
to get things setup?  I know I'm asking an unnatural question as I  
typically start my thinking while staring at the command prompt and  
type commands iteratively till things work.  But I'm just thinking if  
we could maybe figure that out, we could work with someone who does  
have access.


I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
seeing it solved.


-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try  
and convince Apache infra that we need the access.  Seems like they  
are only willing to give accounts on systems to Apache members.


So, I wonder if we could just run our own Confluence instance on  
our zone, only use it to author, then export the content, massage  
and then svn ci.  I guess we could also do the same by moving the  
spaces to goopen.org too, which will provide us the required access  
to implement the site that we all want to implement.


I'm frustrated... we now have a Confluence instance on ASF, but we  
can't really use it to produce the results we want... unless you  
want to see http://geronimo.apache.org become a set of http:// 
cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so that  
http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB looks  
like http://cwiki.apache.org/GMOxKB, etc... but I wonder if that is  
really worth all of the effort.


I guess we could use wget to grab the entire http:// 
cwiki.apache.org/GMOxSITE and then massage and check in... but that  
is terribly inefficient and add more unwanted time lapse between  
updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE the  
official website until there is a way to get access to the exported  
content, or get the httpd configuration changed for our vhost.


I feel like we have a spiffy new Ferrari that we can only drive at  
5 mph... and as soon as you hit 6 mph it starts to hit you on the  
head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try and  
convince Apache infra that we need the access.  Seems like they are  
only willing to give accounts on systems to Apache members.


So, I wonder if we could just run our own Confluence instance on our  
zone, only use it to author, then export the content, massage and  
then svn ci.  I guess we could also do the same by moving the spaces  
to goopen.org too, which will provide us the required access to  
implement the site that we all want to implement.


I'm frustrated... we now have a Confluence instance on ASF, but we  
can't really use it to produce the results we want... unless you want  
to see http://geronimo.apache.org become a set of http:// 
cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so that  
http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB looks  
like http://cwiki.apache.org/GMOxKB, etc... but I wonder if that is  
really worth all of the effort.


I guess we could use wget to grab the entire http://cwiki.apache.org/ 
GMOxSITE and then massage and check in... but that is terribly  
inefficient and add more unwanted time lapse between updating content  
to making the content live.


So, in short... I can't do anything related to making GMOxSITE the  
official website until there is a way to get access to the exported  
content, or get the httpd configuration changed for our vhost.


I feel like we have a spiffy new Ferrari that we can only drive at 5  
mph... and as soon as you hit 6 mph it starts to hit you on the head.


:-(

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Alan D. Cabrera]

Jason,

This is really great!


Regards,
Alan

Jason Dillon wrote:
FYI, I added an Activity section that shows recent JIRA issues 
resolved and opened:


http://cwiki.apache.org/GMOxSITE/

Need a few minor changes to the autoexport plugin to get this kept in 
sync on a regular basis... essentially we need a scheduled export on 
some pages that have more dynamic content.


--jason


On Aug 2, 2006, at 10:13 PM, Alan D. Cabrera wrote:


Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main 
site... but have not fully converted them.  But now you can get a 
better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

I wonder if we could go back to running our own Confluence server in  
our zone... but only to serve as the editing platform... so we could  
install the plugins we want and implement the procedure we need to  
sync up to the "real" website.


That... and its a bit safer in that someone won't nuke all of our  
content when then accidentally import a different install (not just a  
space export).


And it would make it easier for use to backup too... since right new  
we are getting timeouts when exporting that Hernan was talking about.


--jason


On Aug 4, 2006, at 6:59 PM, Matt Hogstrom wrote:


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

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

IMO, there are 2 major issues that need to be resolved before we  
could make this work for our main website:


1) Add a scheduled export feature to AutoExport (w/per space  
configuration)


2) We need access to the file-system that AutoExport uses to write  
static pages so we can massage them a bit and check them into SVN, so  
we can use the mechanism on people.apache.org:/www to sync  
geronimo.apache.org.


 * * *

#1 also implies what we have access to the local file system to  
install a new version of the plugin... and have perms to restart  
Confluence to get the changes picked up.


We also need to get the Utilities plugin installed, so that we can  
make use of a few other advanced macros which will help us make a  
more flexible and dynamic site.


 * * *

I guess if we were forced to we could write a cronjob to "click"  
export on the admin page to export every hour or so.  Which means  
someones account credentials are in the open... :-(


And we could probably use a something to suck down all of the static  
pages via http and then use that as the basis for massaging (fixing  
hostname, etc) and then check that into SVN.


Though... the sync to people and then the sync that it does to make a  
site live will really slow down the edit-view-public cycle.


I wish we had more control over our own websites :-(

--jason


On Aug 4, 2006, at 6:49 PM, Dain Sundstrom wrote:

This is s awesome.  The JIRA integration is the icing on the  
cake for me.  Say we decided to switch over to this today, what do  
we need to do?  And more importantly, what can I do to help?


-dain

On Aug 4, 2006, at 4:32 PM, Jason Dillon wrote:

FYI, I added an Activity section that shows recent JIRA issues  
resolved and opened:


http://cwiki.apache.org/GMOxSITE/

Need a few minor changes to the autoexport plugin to get this kept  
in sync on a regular basis... essentially we need a scheduled  
export on some pages that have more dynamic content.


--jason


On Aug 2, 2006, at 10:13 PM, Alan D. Cabrera wrote:


Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main  
site... but have not fully converted them.  But now you can get  
a better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Geronimo site POC using Confluence & Autoexport

[Matt Hogstrom]

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

Re: Geronimo site POC using Confluence & Autoexport

[Dain Sundstrom]

This is s awesome.  The JIRA integration is the icing on the cake  
for me.  Say we decided to switch over to this today, what do we need  
to do?  And more importantly, what can I do to help?


-dain

On Aug 4, 2006, at 4:32 PM, Jason Dillon wrote:

FYI, I added an Activity section that shows recent JIRA issues  
resolved and opened:


http://cwiki.apache.org/GMOxSITE/

Need a few minor changes to the autoexport plugin to get this kept  
in sync on a regular basis... essentially we need a scheduled  
export on some pages that have more dynamic content.


--jason


On Aug 2, 2006, at 10:13 PM, Alan D. Cabrera wrote:


Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main  
site... but have not fully converted them.  But now you can get a  
better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

Print and Export to PDF buttons are now enabled too.

--jason


On Aug 2, 2006, at 10:13 PM, Alan D. Cabrera wrote:


Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main  
site... but have not fully converted them.  But now you can get a  
better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

FYI, I added an Activity section that shows recent JIRA issues  
resolved and opened:


http://cwiki.apache.org/GMOxSITE/

Need a few minor changes to the autoexport plugin to get this kept in  
sync on a regular basis... essentially we need a scheduled export on  
some pages that have more dynamic content.


--jason


On Aug 2, 2006, at 10:13 PM, Alan D. Cabrera wrote:


Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main  
site... but have not fully converted them.  But now you can get a  
better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Geronimo site POC using Confluence & Autoexport

[Alan D. Cabrera]

Jason Dillon wrote:
FYI... I've updated to include most of the pages from the main site... 
but have not fully converted them.  But now you can get a better feel 
for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason



Looks really great!


Regards,
Alan

Re: Geronimo site POC using Confluence & Autoexport

[David Blevins]

I totally missed this email when it came out.  This stuff rocks!

-David

On Jul 25, 2006, at 3:34 AM, 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

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

FYI... I've updated to include most of the pages from the main  
site... but have not fully converted them.  But now you can get a  
better feel for how the site might look:


 http://cwiki.apache.org/GMOxSITE/

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

On Jul 27, 2006, at 7:35 PM, Bruce Snyder wrote:

Maintenance: I doubt we will be using any custom Confluence plugins,
the infrastructure team doesn't allow that.


We are already using AutoExport... which is custom, and will have to  
either patch it or fork it to fix the remaining issues.


Might also want to look more into a direct SVN plugin, to at the very  
least commit wiki content to SVN.  That could then be used as the  
basis for future work to sync the SVN content back to a space.


Anyways, I don't think we will have a ton of customizations, but I'm  
sure that we will need a few.  I was unaware of any restrictions from  
infra@ regarding plugins for this puppy.


--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

On Jul 27, 2006, at 6:42 PM, John Sisson wrote:
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?


Not that I am aware of :-(

I just end up installing a confluence server.

Someone should embed the personal server into a RCP (Eclipse or  
NetBeans) and then provide a mechanism to sync one local space to a  
remote space (complete pull sync, selective push sync).


--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

I used TimTam a long time ago, and it was really cool... but I don't  
believe it supports offline editing.


Or is that a new feature?

--jason


On Jul 27, 2006, at 7:53 PM, Bruce Snyder wrote:


On 7/27/06, John Sisson <[EMAIL PROTECTED]> wrote:
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?


Try TimTam:

http://timtam.codehaus.org/

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"

);'

Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

On Jul 27, 2006, at 6:17 PM, Jacek Laskowski wrote:

No, definitely not. What I could gather from reading the thread got me
thinking about its wide range of possibilities a few in our team seem
to be able to fully leverage and judge how useful they would
eventually be. I think we need something to keep our web site updated
where *everybody* contributes and if Confluence helps us moving in
this direction even a little, I'm happy to give it a shot.

We can always revert changes and go back to what we've got now, cann't
we? So, unless you're busy with other tasks, I'd ask you to go on.
Will you? ;-)


Okay, I am glad to see there is some support for this.  I do believe  
it is the right direction.


I will continue to work on it when I am not working on m2migration.

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Jeff Genender]

IMHO, I like it a lot.  I would like you to continue.

Jeff

Jason Dillon wrote:
> Is there any desire to continue moving in this direction?
> 
> I personally believe that by having the site in Confluence that it will
> be much easier for us to keep the content up to date, as well as easily
> be able to add new content.
> 
> IMO this is the direction that the Geronimo site should head.
> 
> The question is... shall I continue to set this up (and collaborate with
> others) or would that be a wasted effort?
> 
> --jason
> 
> 
>> On 7/25/06, Jason Dillon <[EMAIL PROTECTED]> 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
>>>
>>>
>>>
>>>
>>>

Re: Geronimo site POC using Confluence & Autoexport

[Bruce Snyder]

On 7/27/06, John Sisson <[EMAIL PROTECTED]> wrote:

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?


Try TimTam:

http://timtam.codehaus.org/

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Re: Geronimo site POC using Confluence & Autoexport

[Bruce Snyder]

On 7/27/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:

On 7/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Is there any desire to continue moving in this direction?
>
> I personally believe that by having the site in Confluence that it
> will be much easier for us to keep the content up to date, as well as
> easily be able to add new content.
>
> IMO this is the direction that the Geronimo site should head.
>
> The question is... shall I continue to set this up (and collaborate
> with others) or would that be a wasted effort?

No, definitely not. What I could gather from reading the thread got me
thinking about its wide range of possibilities a few in our team seem
to be able to fully leverage and judge how useful they would
eventually be. I think we need something to keep our web site updated
where *everybody* contributes and if Confluence helps us moving in
this direction even a little, I'm happy to give it a shot.

We can always revert changes and go back to what we've got now, cann't
we? So, unless you're busy with other tasks, I'd ask you to go on.
Will you? ;-)


This same process is used for both the ActiveMQ and ServiceMix
websites. The websites are completely stored and edited in Confluence
and the same AutoExport plugin is used to automatically export an
edited page to static HTML. The only differences are that we have an
edit link at the very bottom of every page for ease of editing (based
on privs) and some mod_rewrite rules in place for some page names
(IIRC).

Notes to the concerns raised:

Security: Confluence provides it's own users and groups based
security. It's certainly not hardened, but it's good enough.

Performance: The site is not served from Confluence, it's only stored,
edited and exported from there. The site itself is actually static
HTML.

Flexibility: IMO, it's more than flexible enough, especially given
that the Geronimo website shouldn't require anything very
sophisticated. Sure, we could play 'what if' games all week long, but
in the end, it's a static HTML website. Take a look through the
ActiveMQ and ServiceMix websites for further examples.

Maintenance: I doubt we will be using any custom Confluence plugins,
the infrastructure team doesn't allow that. A wiki standard? There is
no such thing and I doubt there ever will be. Migration to any other
wiki requires work just as much migration as does converting Maven's
XDoc format requires for converstion to, say, DocBook.

Versioning: We have never had to roll back the website to this day, so
I'm not too worried about it. But Jason has already proposed a plan
for rsync'ing to Subversion and publishing from Subversion which
sounds like a good plan to me.

Let's not make a moutain out of a mole hill. If the site can be
exported from Confluence and keep the same layout and design, then I
see no issues. Sure, it's different, we'll need to learn a new
process, but someone is willing ot take on the task - that's the
important part. The vast majority of committers have not even touched
the website to date, so to me this is really a non-issue. I say full
steam ahead.

+1

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Re: Geronimo site POC using Confluence & Autoexport

[John Sisson]

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?


Thanks,
John

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

Re: Geronimo site POC using Confluence & Autoexport

[Jacek Laskowski]

On 7/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

Is there any desire to continue moving in this direction?

I personally believe that by having the site in Confluence that it
will be much easier for us to keep the content up to date, as well as
easily be able to add new content.

IMO this is the direction that the Geronimo site should head.

The question is... shall I continue to set this up (and collaborate
with others) or would that be a wasted effort?


No, definitely not. What I could gather from reading the thread got me
thinking about its wide range of possibilities a few in our team seem
to be able to fully leverage and judge how useful they would
eventually be. I think we need something to keep our web site updated
where *everybody* contributes and if Confluence helps us moving in
this direction even a little, I'm happy to give it a shot.

We can always revert changes and go back to what we've got now, cann't
we? So, unless you're busy with other tasks, I'd ask you to go on.
Will you? ;-)

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

Is there any desire to continue moving in this direction?

I personally believe that by having the site in Confluence that it  
will be much easier for us to keep the content up to date, as well as  
easily be able to add new content.


IMO this is the direction that the Geronimo site should head.

The question is... shall I continue to set this up (and collaborate  
with others) or would that be a wasted effort?


--jason



On 7/25/06, Jason Dillon <[EMAIL PROTECTED]> 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

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

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

Re: Geronimo site POC using Confluence & Autoexport

[Hernan Cunico]

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

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

And, we can also use an extra space like GMXxSITE2 for really radical  
changes if needed.


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

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

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

Re: Geronimo site POC using Confluence & Autoexport

[Matt Hogstrom]

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

Re: Geronimo site POC using Confluence & Autoexport

[Jason Dillon]

security -- how will edit access be restricted?  as you know right now
only a committer with an ASF account can change the website (which IMO
is a good thing).   how will that ACL translate to the wiki site and
how will it be maintained?


We can restrict edit to geronimo-users, which should only contain  
commiters... or if needed make a geronimo-commiters group.  Or if we  
really want we can create a new plugin to delegate the list of users  
and authenticate of them to the main database used by Apache, but  
that would take some time to design, implement and convince infra@ to  
allow.


So, short-term we limit the entire GMOxSITE space to edit only by  
members of geronimo-users (or geronimo-commiters).




performance -- the site seems pretty snappy to me but I have heard
some rumblings about confluence performance.  can it handle being
slashdotted?


Well, the site would not be served from Confluence directly.  The  
AutoExport plugin generates static HTML which is served by Apache  
HTTPD... which is hopefully slashdot proof/resistant.


This is static:

http://cwiki.apache.org/GMOxSITE/

This is Confluence:

http://cwiki.apache.org/confluence/display/GMOxSITE/Index

IIRC there is a minor issue where AutoExport renders images and  
attachment links back to Confluence which needs to be resolved along  
with the other minor issues but that is... well... minor ;-)


Also, not sure exactly how http://cwiki.apache.org/GMOxSITE/ would  
get sync'd up to http://geronimo.apache.org.  Could use a virtual  
host and change the CNAME... or probably easier to setup an rsync  
that would automatically update SVN to fit into the normal way that  
sites work now.




flexibility -- is the wiki flexible enough to handle any html/css that
we can throw at it?  for example, the current design was donated by
Epiq a while back and IIUC integrating it into existing website
template system was pretty straightforward.  does confluence present
any limitations that would make this type of activity more difficult?


AutoExport (as well as Confluence itself) use Velocity to render...  
which is what the current site uses (via Ankia).  Take a peek at the  
GMOxSITE.vsl velocity template I attached in the initial email which  
shows how any HTML can be used for the main skin.


So... its basically the same.  With the exception that AutoExport is  
using Velocity configured from inside of Confluence and has full  
access to the Confluence context variables as well as the plugin  
framework which allows other context variables to be added.


One of the main advantages of using Confluence is not not have to  
worry about HTML to make great looking pages.  So in most cases we  
don't want actually content pages to use HTML, though in some cases  
we need to, and it is easy to make a user macro for that.  In fact I  
had to do this for the "News Archive" link...




maintenance -- how much Confluence expertise will it require to
maintain the site, especially if we start using custom plugins, etc?


Custom plugins will add a certain level of additional knowledge...  
enough to well... know how to write custom plugins ;-)


But I don't see that we will be doing very much of that... at least  
not right now.  The only custom plugin work that needs to be done is  
to get some fixes into the AutoExport plugin (unless they are already  
fixed).




how hard would it be to migrate the site contents to a different Wiki
system or to revert back to a "standard" website if that became
necessary?


Well... that all depends on what "standard" means.  If standard means  
raw html, then... well no effort, since the site exports to HTML...  
only a small change to the template to remove the Confluence page  
actions, then regenerate the site and done.


If standard means back to Ankia, then a bit of work to whip up a  
template to generate the proper xdocs xml files, then run that once  
to generate new files from Confluence and then a tad bit of tidying  
up to get it all working from Ankia again.  Not trivial... but not  
too difficult either.


As for different wiki... well... I'd rather not go there.  But if we  
did need to then it would be very similar to the above, with a custom  
velocity template, this one would not render the pages, but just  
include the raw wiki.  Then some sort of wiki syntax converter would  
be needed to translate to the target wiki's language.



Again I really like the work you've done and think it shows a lot  
of promise.


Thanks,

--jason

Re: Geronimo site POC using Confluence & Autoexport

[Paul McMahan]

Jason,  nice work!  Using a wiki for the website will make it easier
to make changes to the website. This also allows the website to take
advantage of the many bells and whistles in Confluence.

A few questions:

security -- how will edit access be restricted?  as you know right now
only a committer with an ASF account can change the website (which IMO
is a good thing).   how will that ACL translate to the wiki site and
how will it be maintained?

performance -- the site seems pretty snappy to me but I have heard
some rumblings about confluence performance.  can it handle being
slashdotted?

flexibility -- is the wiki flexible enough to handle any html/css that
we can throw at it?  for example, the current design was donated by
Epiq a while back and IIUC integrating it into existing website
template system was pretty straightforward.  does confluence present
any limitations that would make this type of activity more difficult?

maintenance -- how much Confluence expertise will it require to
maintain the site, especially if we start using custom plugins, etc?
how hard would it be to migrate the site contents to a different Wiki
system or to revert back to a "standard" website if that became
necessary?

Again I really like the work you've done and think it shows a lot of promise.

Best wishes,
Paul

On 7/25/06, Jason Dillon <[EMAIL PROTECTED]> 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