See below. On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:
> 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 The above concerns me a bit. Log4j2 is a multi-module site. My plan has always been to use site:deploy or site:stage-deploy to get the site to wherever it has to go to be processed by svnpubsub. From what you are saying I can't tell if that will work or not as I would not modify the output directory for a multi-module build as it won't accomplish anything and I'm not sure at all why I would want to modify the siteDirectory to build the Log4j2 site. Ralph > > 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 > > > > > > >
