I generally post the Log4j web site to my github.io <http://github.io/> account 
for review before publishing it live. That way everyone can see what it looks 
like.

Ralph

> On Oct 30, 2019, at 1:31 PM, Kate Gray <[email protected]> wrote:
> 
> If the UTF-8 issue isn’t fixed, I’ll fix it.
> 
> I’m going to go ahead and use my GitHub fork to put together a demo site.  If 
> the project owners like it, I’ll put it in a PR.
> 
> I’ll try to do something like symfony’s multi version documentation so that 
> we can release a v3 without obliterating the v2 docs.
> 
> Kate
> ________________________________
> From: Christian Grobmeier <[email protected]>
> Sent: Wednesday, October 30, 2019 7:45:08 AM
> To: [email protected] <[email protected]>
> Subject: Re: [LOG4PHP] Site Generation
> 
> I would love if we could separate the logging pages from the release cycle.
> There was once a blocker using Phing, I think it had something to do with not 
> supporting UTF-8 correclty. Most likely this is gone by now and I would be 
> fine to move on.
> 
> 
> --
>  Christian Grobmeier
>  [email protected]
> 
> On Wed, Oct 30, 2019, at 05:04, Ralph Goers wrote:
>> FWIW,
>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>>  
>> <https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site>
>>  discusses how the logging services web site and the individual logging 
>> projects are built.  I’ve heard rumblings that the ASF CMS is being or has 
>> been replaced or that you can at least use git but I haven’t investigated 
>> that. I can tell you I have a love/hate relationship with how the Log4j 
>> documentation is created. For Java it makes more sense since it generates 
>> some neat stuff automatically but I am not sure what added value it would 
>> bring to a project like log4php.
>> 
>> So as far as that goes, the only thing that matters is that the source
>> for the site is in source control - we could even request a GitHub
>> project to host all the logging subproject web sites if we want - and
>> that the generated site(s) are checked in to match ASF Infra’s
>> expectations. You can read about the ASF CMS at
>> https://www.apache.org/dev/cms <https://www.apache.org/dev/cms>, The
>> only documentation on using git for the rendered site that I could find
>> is at https://blogs.apache.org/infra/entry/git_based_websites_available
>> <https://blogs.apache.org/infra/entry/git_based_websites_available>.
>> 
>> Ralph
>> 
>>> On Oct 29, 2019, at 8:35 PM, Kate Gray <[email protected]> wrote:
>>> 
>>> I've updated some of the source documents.  It looks like it's pretty 
>>> broken - apigen, for example, isn't stable above PHP5.    The Release 
>>> Candidate is really brittle, requiring specific commits of other libraries.
>>> 
>>> There's an issue, LOG4PHP-192, that mentions using phing.  As I mentioned 
>>> in the issue, I'm personally in favor of using phing, as it would make it 
>>> possible to build .phar (compiled archives) that are a bit easier to work 
>>> with.  A lot of tools are distributed that way these days.
>>> 
>>> If we're just generating .html files, we could go the native PHP way and 
>>> use Sculpin to generate the site.  It takes twig (a simple template 
>>> engine), markdown and spits out static HTML.
>>> 
>>> API documentation could be done with phpDocumentor, phpDox, or doxygen.  
>>> I'm a bit partial to phpDox personally.
>>> 
>>> What do people think?
>>> 
>>> Kate
>> 
>> 

Reply via email to