You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Benson Margulies <bi...@gmail.com> on 2011/02/11 13:15:24 UTC
Web site and Confluence
Currently, the deployed site is a 'forrest' antique.
We have some pretty reasonable content sitting in Confluence. As you
may know, in general, intrastructure@apache is pushing projects from
Confluence to their new Markdown+svn CMS. The reason is their problems
with the generic export technology used historically with Confluence.
Some of us are not really thrilled at editing Markdown in a text
editor or web browser.
Dan Kulp has gone and created an alternative Confluence export device.
It meets the strictures of infrastructure@ and it allows site
maintenance in Confluence.
I'd like to make ws.apache.org use Confluence (with some maven site
output as appropriate), using Dan's technology. Anybody object?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Andreas Veithen <an...@gmail.com>.
I don't think that any of the subprojects publish their sites directly
to people.apache.org. The standard workflow is as follows:
1. Generate the site locally.
2. Commit the site to SVN.
3. Do an svn update on people.apache.org.
4. Wait for the find+rsync stuff to synchronize the live site. This
can take several hours.
SvnPubSub would simplify this process a lot because it eliminates
items 3 and 4. I think that in order to use SvnPubSub, the only
requirement for us would be consolidate the different parts of the
site into a single tree in SVN (right now, different subdirectories on
people.apache.org:/www/ws.apache.org are working directories checked
out from different locations in SVN) [1]. Since there are still a
couple of pending todo items from the Axis TLP migration (there is
still some Axis stuff on ws.apache.org), this would be a good occasion
to work on this consolidation.
Anyway, for the SvnPubSub vs. find+rsync question, I fully agree with
the point of view of the infrastructure team. Therefore I think it's
best to include SvnPubSub in the scope of the Web site changes as soon
as possible, and not to wait for 2012. However, that would mean that
your export tool must be able to commit changes to SVN. Do you think
that it's feasible to include that requirement into the scope?
Andreas
[1] Looking at the source code of the commit hook for SvnPubSub, I
don't see anything that would be able to handle SVN externals, so we
really need to move the different parts of the site into a single
location.
On Mon, Feb 14, 2011 at 16:22, Daniel Kulp <dk...@apache.org> wrote:
> On Sunday 13 February 2011 5:02:26 PM Andreas Veithen wrote:
>> The very same idea of using an external tool instead of the export
>> plugin also came to my mind, but I didn't have the time to explore
>> this idea further. I'm +1 for this provided that the following
>> conditions are met:
>>
>> 1. We have volunteers to implement the Confluence solution. That seems
>> to be the case.
>
> Yep. :-)
>
>> 2. We can make sure that this solution doesn't cause us troubles with
>> intrastructure@apache.org.
>
> Well, I cannot guarantee that. infra seems to not like anything written in
> java, builds with java, has anything remotely to do with java, or even has the
> letters 'J', 'A', and 'V' in the name. :-(
>
>> 3. We have no strong proponents of the Markdown solution who would
>> also volunteer to do it with their solution. (If there are volunteers,
>> then we should evaluate more thoroughly the pros and cons of the two
>> solutions)
>> 4. There is no impact on subprojects that want to continue using
>> (Maven) generated sites.
>
> This is something that will need to be re-investigated longer term. The
> external confluence exporter certainly will allow that short term. The CMS
> WOULD have an issue as the entire site needs to be committed into svn in a
> single tree. Thus, the projects would all need to be reconfigured to stick
> them into a particular area of the svn checkout.
>
> Longer term (like in 2012), we WILL need to re-look at this. infra wants all
> sites to go through svnpubsub which will require all site to be in svn. That
> said, I would expect the maven folks to have something figured out by then
> since the entire maven site is built that way. Thus, it may or may not be
> something we'll need to worry about.
>
>
> Dan
>
>
>>
>> Andreas
>>
>> On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com>
> wrote:
>> > Currently, the deployed site is a 'forrest' antique.
>> >
>> > We have some pretty reasonable content sitting in Confluence. As you
>> > may know, in general, intrastructure@apache is pushing projects from
>> > Confluence to their new Markdown+svn CMS. The reason is their problems
>> > with the generic export technology used historically with Confluence.
>> >
>> > Some of us are not really thrilled at editing Markdown in a text
>> > editor or web browser.
>> >
>> > Dan Kulp has gone and created an alternative Confluence export device.
>> > It meets the strictures of infrastructure@ and it allows site
>> > maintenance in Confluence.
>> >
>> > I'd like to make ws.apache.org use Confluence (with some maven site
>> > output as appropriate), using Dan's technology. Anybody object?
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: dev-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.org
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday 13 February 2011 5:02:26 PM Andreas Veithen wrote:
> The very same idea of using an external tool instead of the export
> plugin also came to my mind, but I didn't have the time to explore
> this idea further. I'm +1 for this provided that the following
> conditions are met:
>
> 1. We have volunteers to implement the Confluence solution. That seems
> to be the case.
Yep. :-)
> 2. We can make sure that this solution doesn't cause us troubles with
> intrastructure@apache.org.
Well, I cannot guarantee that. infra seems to not like anything written in
java, builds with java, has anything remotely to do with java, or even has the
letters 'J', 'A', and 'V' in the name. :-(
> 3. We have no strong proponents of the Markdown solution who would
> also volunteer to do it with their solution. (If there are volunteers,
> then we should evaluate more thoroughly the pros and cons of the two
> solutions)
> 4. There is no impact on subprojects that want to continue using
> (Maven) generated sites.
This is something that will need to be re-investigated longer term. The
external confluence exporter certainly will allow that short term. The CMS
WOULD have an issue as the entire site needs to be committed into svn in a
single tree. Thus, the projects would all need to be reconfigured to stick
them into a particular area of the svn checkout.
Longer term (like in 2012), we WILL need to re-look at this. infra wants all
sites to go through svnpubsub which will require all site to be in svn. That
said, I would expect the maven folks to have something figured out by then
since the entire maven site is built that way. Thus, it may or may not be
something we'll need to worry about.
Dan
>
> Andreas
>
> On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com>
wrote:
> > Currently, the deployed site is a 'forrest' antique.
> >
> > We have some pretty reasonable content sitting in Confluence. As you
> > may know, in general, intrastructure@apache is pushing projects from
> > Confluence to their new Markdown+svn CMS. The reason is their problems
> > with the generic export technology used historically with Confluence.
> >
> > Some of us are not really thrilled at editing Markdown in a text
> > editor or web browser.
> >
> > Dan Kulp has gone and created an alternative Confluence export device.
> > It meets the strictures of infrastructure@ and it allows site
> > maintenance in Confluence.
> >
> > I'd like to make ws.apache.org use Confluence (with some maven site
> > output as appropriate), using Dan's technology. Anybody object?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: dev-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Andreas Veithen <an...@gmail.com>.
The very same idea of using an external tool instead of the export
plugin also came to my mind, but I didn't have the time to explore
this idea further. I'm +1 for this provided that the following
conditions are met:
1. We have volunteers to implement the Confluence solution. That seems
to be the case.
2. We can make sure that this solution doesn't cause us troubles with
intrastructure@apache.org.
3. We have no strong proponents of the Markdown solution who would
also volunteer to do it with their solution. (If there are volunteers,
then we should evaluate more thoroughly the pros and cons of the two
solutions)
4. There is no impact on subprojects that want to continue using
(Maven) generated sites.
Andreas
On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com> wrote:
> Currently, the deployed site is a 'forrest' antique.
>
> We have some pretty reasonable content sitting in Confluence. As you
> may know, in general, intrastructure@apache is pushing projects from
> Confluence to their new Markdown+svn CMS. The reason is their problems
> with the generic export technology used historically with Confluence.
>
> Some of us are not really thrilled at editing Markdown in a text
> editor or web browser.
>
> Dan Kulp has gone and created an alternative Confluence export device.
> It meets the strictures of infrastructure@ and it allows site
> maintenance in Confluence.
>
> I'd like to make ws.apache.org use Confluence (with some maven site
> output as appropriate), using Dan's technology. Anybody object?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Colm O hEigeartaigh <co...@apache.org>.
+1. The WSS4J website is in dire need of an update, and I'd much
rather do it via a wiki.
Colm.
On Fri, Feb 11, 2011 at 12:15 PM, Benson Margulies
<bi...@gmail.com> wrote:
> Currently, the deployed site is a 'forrest' antique.
>
> We have some pretty reasonable content sitting in Confluence. As you
> may know, in general, intrastructure@apache is pushing projects from
> Confluence to their new Markdown+svn CMS. The reason is their problems
> with the generic export technology used historically with Confluence.
>
> Some of us are not really thrilled at editing Markdown in a text
> editor or web browser.
>
> Dan Kulp has gone and created an alternative Confluence export device.
> It meets the strictures of infrastructure@ and it allows site
> maintenance in Confluence.
>
> I'd like to make ws.apache.org use Confluence (with some maven site
> output as appropriate), using Dan's technology. Anybody object?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Benson Margulies <bi...@gmail.com>.
Dan,
Sorry to expose your machinations prematurely, but I couldn't see
deploying this on the ws project without discussing it with the ws
PMC. And the thought of extensive 'forrestry' to get the site up to
speed is pretty depressing.
--benson
On Fri, Feb 11, 2011 at 11:09 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Ok, thx for the info.
>
> FWIW, we've just switched the Karaf web site to a scalate based site,
> so the backend is svn and we use a 'mvn scalate:deploy' to deploy a
> version of the site on the ASF hardware. This allows offline editing,
> real patches contributions, and even eventually branches for
> experiments, etc...
> The original content was grabbed from confluence so we're still using
> the same markup language ...
>
> On Fri, Feb 11, 2011 at 17:04, Daniel Kulp <dk...@apache.org> wrote:
>> On Friday 11 February 2011 7:42:53 am Guillaume Nodet wrote:
>>> On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com>
>> wrote:
>>> > Currently, the deployed site is a 'forrest' antique.
>>> >
>>> > We have some pretty reasonable content sitting in Confluence. As you
>>> > may know, in general, intrastructure@apache is pushing projects from
>>> > Confluence to their new Markdown+svn CMS. The reason is their problems
>>> > with the generic export technology used historically with Confluence.
>>> >
>>> > Some of us are not really thrilled at editing Markdown in a text
>>> > editor or web browser.
>>> >
>>> > Dan Kulp has gone and created an alternative Confluence export device.
>>> > It meets the strictures of infrastructure@ and it allows site
>>> > maintenance in Confluence.
>>>
>>> I wasn't aware of this work. Is there any info available on that ?
>>
>> Well, I wasn't actually planning to make it public yet as I don't have the
>> time right now to have battles with Joe..... :-)
>>
>> Seriously, for 2 weeks now, CXF has not used the AutoExport plugin of
>> confluence. The fact that no-one has noticed any functional difference is a
>> good thing. It means it's working fairly well.
>>
>> Basically, in my cron, instead of using rsync to copy the exported content, I
>> have a little java program that uses the Confluence SOAP API (the confluence
>> REST api doesn't provide enough functionality, I tried) to grab the content
>> and then run velocity locally to generate the site. In the process, it runs
>> the HTML through tagsoup and does a bunch of attribute filtering and such to
>> fix the HTML (and all the links and such as well). Thus, the resulting HTML
>> is much better than the auto-export version. The CXF home page, for example,
>> is HTML4/Transitional compliant now whereas it had 40+ errors (using the w3c
>> validator) with the autoexport version.
>>
>> It does cache the mod times (file on disk) of the pages and such so only
>> changed pages get regenerated. However, it's also smart enough to detect when
>> one of the key pages (like Navigation and Banner) get updated to force a full
>> rebuild. (autoexport doesn't do that) It also checks the RSS feed before any
>> of the SOAP calls just to save time/resources. If no RSS changes, it exits
>> fast. Another note: it doesn't do this yet, but it can easily detect page
>> deletions and delete the files as well. I just need to add that. autoexport
>> cannot do that at all right now.
>>
>> Right now, it just writes the files out to a directory. At some point, I
>> want to update it to support subversion so it can auto checkin the files into
>> subversion. That would allow svnpubsub usage for publishing the site live.
>> I could then also move it from a cron to a build in buildbot or hudson. That
>> would allow "instant" site updated by just launching a build as needed.
>>
>> If anyone wants to play with it:
>> http://svn.apache.org/repos/asf/cxf/web/
>>
>>
>> Dan
>>
>>>
>>> > I'd like to make ws.apache.org use Confluence (with some maven site
>>> > output as appropriate), using Dan's technology. Anybody object?
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: dev-help@ws.apache.org
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Guillaume Nodet <gn...@gmail.com>.
Ok, thx for the info.
FWIW, we've just switched the Karaf web site to a scalate based site,
so the backend is svn and we use a 'mvn scalate:deploy' to deploy a
version of the site on the ASF hardware. This allows offline editing,
real patches contributions, and even eventually branches for
experiments, etc...
The original content was grabbed from confluence so we're still using
the same markup language ...
On Fri, Feb 11, 2011 at 17:04, Daniel Kulp <dk...@apache.org> wrote:
> On Friday 11 February 2011 7:42:53 am Guillaume Nodet wrote:
>> On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com>
> wrote:
>> > Currently, the deployed site is a 'forrest' antique.
>> >
>> > We have some pretty reasonable content sitting in Confluence. As you
>> > may know, in general, intrastructure@apache is pushing projects from
>> > Confluence to their new Markdown+svn CMS. The reason is their problems
>> > with the generic export technology used historically with Confluence.
>> >
>> > Some of us are not really thrilled at editing Markdown in a text
>> > editor or web browser.
>> >
>> > Dan Kulp has gone and created an alternative Confluence export device.
>> > It meets the strictures of infrastructure@ and it allows site
>> > maintenance in Confluence.
>>
>> I wasn't aware of this work. Is there any info available on that ?
>
> Well, I wasn't actually planning to make it public yet as I don't have the
> time right now to have battles with Joe..... :-)
>
> Seriously, for 2 weeks now, CXF has not used the AutoExport plugin of
> confluence. The fact that no-one has noticed any functional difference is a
> good thing. It means it's working fairly well.
>
> Basically, in my cron, instead of using rsync to copy the exported content, I
> have a little java program that uses the Confluence SOAP API (the confluence
> REST api doesn't provide enough functionality, I tried) to grab the content
> and then run velocity locally to generate the site. In the process, it runs
> the HTML through tagsoup and does a bunch of attribute filtering and such to
> fix the HTML (and all the links and such as well). Thus, the resulting HTML
> is much better than the auto-export version. The CXF home page, for example,
> is HTML4/Transitional compliant now whereas it had 40+ errors (using the w3c
> validator) with the autoexport version.
>
> It does cache the mod times (file on disk) of the pages and such so only
> changed pages get regenerated. However, it's also smart enough to detect when
> one of the key pages (like Navigation and Banner) get updated to force a full
> rebuild. (autoexport doesn't do that) It also checks the RSS feed before any
> of the SOAP calls just to save time/resources. If no RSS changes, it exits
> fast. Another note: it doesn't do this yet, but it can easily detect page
> deletions and delete the files as well. I just need to add that. autoexport
> cannot do that at all right now.
>
> Right now, it just writes the files out to a directory. At some point, I
> want to update it to support subversion so it can auto checkin the files into
> subversion. That would allow svnpubsub usage for publishing the site live.
> I could then also move it from a cron to a build in buildbot or hudson. That
> would allow "instant" site updated by just launching a build as needed.
>
> If anyone wants to play with it:
> http://svn.apache.org/repos/asf/cxf/web/
>
>
> Dan
>
>>
>> > I'd like to make ws.apache.org use Confluence (with some maven site
>> > output as appropriate), using Dan's technology. Anybody object?
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: dev-help@ws.apache.org
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 11 February 2011 7:42:53 am Guillaume Nodet wrote:
> On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com>
wrote:
> > Currently, the deployed site is a 'forrest' antique.
> >
> > We have some pretty reasonable content sitting in Confluence. As you
> > may know, in general, intrastructure@apache is pushing projects from
> > Confluence to their new Markdown+svn CMS. The reason is their problems
> > with the generic export technology used historically with Confluence.
> >
> > Some of us are not really thrilled at editing Markdown in a text
> > editor or web browser.
> >
> > Dan Kulp has gone and created an alternative Confluence export device.
> > It meets the strictures of infrastructure@ and it allows site
> > maintenance in Confluence.
>
> I wasn't aware of this work. Is there any info available on that ?
Well, I wasn't actually planning to make it public yet as I don't have the
time right now to have battles with Joe..... :-)
Seriously, for 2 weeks now, CXF has not used the AutoExport plugin of
confluence. The fact that no-one has noticed any functional difference is a
good thing. It means it's working fairly well.
Basically, in my cron, instead of using rsync to copy the exported content, I
have a little java program that uses the Confluence SOAP API (the confluence
REST api doesn't provide enough functionality, I tried) to grab the content
and then run velocity locally to generate the site. In the process, it runs
the HTML through tagsoup and does a bunch of attribute filtering and such to
fix the HTML (and all the links and such as well). Thus, the resulting HTML
is much better than the auto-export version. The CXF home page, for example,
is HTML4/Transitional compliant now whereas it had 40+ errors (using the w3c
validator) with the autoexport version.
It does cache the mod times (file on disk) of the pages and such so only
changed pages get regenerated. However, it's also smart enough to detect when
one of the key pages (like Navigation and Banner) get updated to force a full
rebuild. (autoexport doesn't do that) It also checks the RSS feed before any
of the SOAP calls just to save time/resources. If no RSS changes, it exits
fast. Another note: it doesn't do this yet, but it can easily detect page
deletions and delete the files as well. I just need to add that. autoexport
cannot do that at all right now.
Right now, it just writes the files out to a directory. At some point, I
want to update it to support subversion so it can auto checkin the files into
subversion. That would allow svnpubsub usage for publishing the site live.
I could then also move it from a cron to a build in buildbot or hudson. That
would allow "instant" site updated by just launching a build as needed.
If anyone wants to play with it:
http://svn.apache.org/repos/asf/cxf/web/
Dan
>
> > I'd like to make ws.apache.org use Confluence (with some maven site
> > output as appropriate), using Dan's technology. Anybody object?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: dev-help@ws.apache.org
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: Web site and Confluence
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 11, 2011 at 13:15, Benson Margulies <bi...@gmail.com> wrote:
> Currently, the deployed site is a 'forrest' antique.
>
> We have some pretty reasonable content sitting in Confluence. As you
> may know, in general, intrastructure@apache is pushing projects from
> Confluence to their new Markdown+svn CMS. The reason is their problems
> with the generic export technology used historically with Confluence.
>
> Some of us are not really thrilled at editing Markdown in a text
> editor or web browser.
>
> Dan Kulp has gone and created an alternative Confluence export device.
> It meets the strictures of infrastructure@ and it allows site
> maintenance in Confluence.
I wasn't aware of this work. Is there any info available on that ?
>
> I'd like to make ws.apache.org use Confluence (with some maven site
> output as appropriate), using Dan's technology. Anybody object?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org