Re: Logging web sites

Le samedi 9 juin 2012 15:31:36 Ralph Goers a écrit :

Thanks, that did the trick.  I have published both the 1.2 and 2.0 sites to 
loggingtest.apache.org. 
yeah!


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. 
"svn co --depth n" is an easy workaround

 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.
the publish plugin does not only check-in html, but it normalizes newlines too 
(for the case where the skin hasn't been published from the same platform as 
the site using it). But these 2 simple tasks can be done without publish 
plugin: the plugin more complex task is to update content, which you don't 
seem to expect (simple independent imports for each version)

 Each of the other sub-sites should do the same thing.
+1, whatever their html generation engine is, release procedure should now 
contain publishing the documentation html content to svn and doing a symlink


Ralph

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)
 
Regards,
 
Hervé
 
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.


Ralph




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