from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)

To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk

notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:

1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>

2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants

Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/

(notice this in in infra repo)

(notice this does not contain subsites, look at plugins directory)

(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:

https://svn.apache.org/repos/infra/websites/production/maventest/content/

This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:

- add trunk

- move src/site to content

- add resources/extpath.txt

- add a way to configure output directory from command line

Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  


So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.


Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general@logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph