deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@gmail.com>
Subject Re: [suggestion] - Documentation
Date Wed, 25 Jul 2012 00:37:39 GMT
The answer to both these questions really that the CMS creates "websites", some details on
that below

I'll note that the CMS is svn based -- maybe undesirable given the use of git.

On Jul 24, 2012, at 4:54 PM, Shane Bryzak wrote:

> Does the choice of Apache CMS for hosting documentation meet the following requirements?
> 
> 1) Making available the documentation for previously released versions of DeltaSpike.

If by "make available" the intention is browsable on the website, then sure there are ways
to handle that.

> 2) Making available the documentation in offline formats, such as HTML or PDF available
for download.

Certainly you can use the same source to generate non-website looking HTML.  Same goes for
PDF.

You wouldn't be using the CMS to do this, but the CMS doesn't prevent it.  It'd be something
we setup ourselves and could be done via a CI server or something done at release time.

Basically the CMS is a system that is for generate website html using the following layout:

 - content/<source-files-and-directories>
 - lib/<site-generating-perl-functions>
 - templates/<whatever-you-need-for-templates>

When something in 'content/' is updated, it will run it through lib/ (which leverages templates/)
and save the resulting html to disk and take care of synching that html file from staging
to production.

When something in 'lib/' or 'templates/' is updated, it pretends as if everything in 'content/'
has changed and performs the above step on every source file.

You can organize the 'content/' dir however you want.  That could mean:

 - content/v0.1/
 - content/v0.2/
 - content/current/

Where 'current' gets versioned on release.  Or anything at all.  Maybe just:

 - content/<wild-wild-west>


So the short answer is there isn't anything there to prevent or help the two points.

In terms of generating outside the CMS which is what would be needed for say, turning many
files into one file such as a zip of html or a PDF, it's up to us.  There are projects that
do it via buildbot.  Buildbot is not so much a CI tool as it is "cron with a webUI" and also
happens to have the ability to be trigger by commits.

Really, you can get anything done with buildbot without much in the way of restrictions. 
It's a mediocre CI system and an amazing cron replacement.


-David


Mime
View raw message