Thanks, that did the trick.  I have published both the 1.2 and 2.0 sites to

This is actually pretty easy but we will want a way to exclude the sub-sites when the production site is checked out to add a new project.  We really don't need to use the maven publish plugin as I've checked in the each project in its own release directly and then used a symlink to point the project site to the specific release.  Each of the other sub-sites should do the same thing.


On Jun 9, 2012, at 10:19 AM, Hervé BOUTEMY wrote:

yes, that's it, you manually commit them to the production site.
Then extpath is there to avoid deleting them when staging area is promoted to production (or mre precisely to put them back after the production site has been overrided with staging area content)






Le samedi 9 juin 2012 09:13:05 Ralph Goers a écrit :

Hervé, now that the main site is there I am still trying to figure out how the extpath stuff works.  Below you say when the staging area is promoted to production, "This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.". How does this happen? How does the production structure know where to get them from. Or do you manually commit them to the production site? I'm thinking it has to be the latter.


On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:

from my experience with maventest


- the whole generated html goes into (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:
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"):


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:
(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:
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, 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.






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.

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.






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

Here was what Ivan proposed -


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






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 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.