Re: migrating the main site to the CMS- a simple approach

> From: Joe Schaefer <joe_schaefer@...>
> To: sebb <sebbaz@...>; "general@..." <general@...>
> Cc:
> Sent: Tuesday, February 14, 2012 1:47 PM
> Subject: Re: migrating the main site to the CMS- a simple approach
>
> ----- Original Message -----
>
>>  From: sebb <sebbaz@...>
>>  To: general@...; Joe Schaefer
> <joe_schaefer@...>
>>  Cc:
>>  Sent: Tuesday, February 14, 2012 1:36 PM
>>  Subject: Re: migrating the main site to the CMS- a simple approach
>>
>>  On 14 February 2012 18:09, Joe Schaefer <joe_schaefer@...>
> wrote:
>>>   ----- Original Message -----
>>>
>>>>   From: sebb <sebbaz@...>
>>>>   To: general@...; Joe Schaefer
>>  <joe_schaefer@...>
>>>>   Cc:
>>>>   Sent: Tuesday, February 14, 2012 1:04 PM
>>>>   Subject: Re: migrating the main site to the CMS- a simple approach
>>>>
>>>>   On 14 February 2012 17:08, Joe Schaefer
> <joe_schaefer@...>
>>  wrote:
>>>>>    ----- Original Message -----
>>>>>
>>>>>>    From: Joe Schaefer <joe_schaefer@...>
>>>>>>    To: "general@..."
>>>>   <general@...>
>>>>>>    Cc:
>>>>>>    Sent: Tuesday, February 14, 2012 12:04 PM
>>>>>>    Subject: Re: migrating the main site to the CMS- a simple
>
>>  approach
>>>>>>
>>>>>>>    ________________________________
>>>>>>>     From: sebb <sebbaz@...>
>>>>>>>    To: general@...
>>>>>>>    Sent: Tuesday, February 14, 2012 11:57 AM
>>>>>>>    Subject: Re: migrating the main site to the CMS- a
> simple
>>  approach
>>>>>>>
>>>>>>>    On 14 February 2012 16:21, Joe Schaefer
>>>>   <joe_schaefer@...>
>>>>>>    wrote:
>>>>>>>>     So I realize that I don't have enough time
> myself
>>>>>>>>     to convert the incubator site's content to
>>  markdown
>>>>>>>>     even tho there are scripts to automate that
> process.
>>>>>>>>     Instead let me offer a different idea- to keep
> the
>>>>>>>>     existing build system but superimpose the CMS on
> top
>>>>>>>>     of it.
>>>>>>>
>>>>>>>>     To facilitate this, all that needs to happen is
> for
>>>>>>>>     someone to find a generic way of invoking anakia
> so
>>>>>>>>     it satisfies the command-line interface of
>>>>>>>>
>>>>>>>>
>>>>
>>   https://svn.apache.org/repos/infra/websites/cms/build/build_external.pl
>>>>>>>>
>>>>>>>>     (ie builds sources from ./content/ into a
> specified
>>  target
>>>>>>>>     dir).
>>>>>>>
>>>>>>>    That's not actually sufficient to build the main
>>  Incubator
>>>>   site,
>>>>>>>    because it does not take the Clutch updates into
> account.
>>>>>>>
>>>>>>>    However, I guess Clutch could be run separately to
> update
>>  the
>>>>   source
>>>>>>>    files, and then trigger a site rebuild.
>>>>>
>>>>>    Alternately, if the clutch builds simply modify source
> content,
>>>>
>>>>   Yes, that's all it does.
>>>>
>>>>>    that aspect can be performed manually and the build system
> will
>>>>>    generate that content from the changes to the source content.
>>>>>    All someone would have to do in addition to what they already
>>>>>    already do now is publish the changes to the live site.
>>>>
>>>>   However, the site build does a lot more than just run Anakia.
>>>>
>>>>   It also runs XSLT and texen; each is run several times with
> different
>>  data.
>>>>   There are some other stages as well.
>>>>
>>>>   This is all done by Ant, using the build.xml from the top-level
>>  directory.
>>>>
>>>>   I suspect this is also true of a lot of other sites which use
> Anakia.
>>>
>>>   Well whatever- we can change the build type from anakia to ant. 
> That's
>>>   no big deal.  All we need at this point for CMS support is:
>>>
>>>   1) to change the name of the directory holding the site sources to
>>  "content",
>>
>>  The sources are held under:
>>  https://svn.apache.org/repos/asf/incubator/public/trunk/site-author
>
> So rename site-author to "content".  That'd be step 1 precisely.
>
>>
>>  However, there are support files in other directories, in particular
>>  the lib/ directory.
>
> That has no material impact on what I'm proposing: just leave those
> where they are.
>
>>
>>>   2) to figure out what command-line arguments to pass to ant or to
> build.sh
>>  or
>>>   whatever to tell it to build to a specified target directory also
> named
>>  "content"
>>>   but with a different base directory.
>>
>>  The output currently goes to
>>  https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish.
>>
>>  I think most files under site-publish are derived from site-author;
>>  however there are probably some that are only in site-publish.
>>  For example, .htaccess seems to be only in site-publish.
>
> Well that would need to go into the "content" dir and ant would need
> to copy it over to the target "content" dir.
>
>>
>>  Probably the first task is to ensure that all site-publish files are
>>  derivable from site-author.
>
> Yes.
>
>>
>>  Can then rename the input directory, and fix up the build file.
>>
>>  Changing the output directory would be a bit more involved as it is
>>  used for the workspace on minotaur.
>
> Well can't we make this configurable?  I mean cmon it's 2012, surely
> we can pass some argument to build.sh that tells it to use a different
> directory other than site-publish.
>
>>  Would it be possible to switch to the eventual svnpubsub target
>>  without actually switching to CMS yet?
>>  Could then switch the workspace on minotaur to use the new content
>>  output directory.
>>
>>  Once that's working, then CMS could be plugged in.
>
> I've outlined the approach I recommend- to rename the source dir,
> make everything that's in the output dir come from the build process
> (not necessarily the source dir), and to make the target dir a command-line
> option to build.sh / ant / whatever.