it would be great if somebody tried some maventest site modification, just to check I'm not the only one understanding the CMS :) the only limitation is actually that site build by buildbot costs 2 minutes, and you should not publish before the build is finished
now I thought more on components publication. My proposed workflow has the advantage of being quite simple. But there is a drawback: each file of the release is fully independent of previous releases, so it does not create any real history of the site, it is just independent publication. To have a real history, we could publish each component site in a dedicated svn tree, then publication in maventest content would be a copy of specific versions for example: https://svn.apache.org/repos/infra/websites/production/maventest/ components/ant-tasks : publish each build here content/ant-tasks-2.1.3 : copy of previous directory on the appropriate revision and once again content/ant-tasks = symlink to ant-tasks-2.1.3 IMHO, such organization would be more appropriate to track history of each component sites. The drawback I see is that it will require some svn commands not so easy to do without a full svn checkout of the whole site (we should avoid svn co of the whole site, since it is actually more than 5 GB...) any other idea? Le vendredi 2 mars 2012 00:41:39 Hervé BOUTEMY a écrit : > as you may have remarked from some "little" commit logs, Joe put a test site > for CMS+svnpubsub of Maven site online [1], with a full CMS integration of > site build using Maven (thank you Joe) > > What was done to adapt the site to the CMS integration is quickly documented > in CMS adoption page [2] > > > The result is as follow: each page of the Maven site can be edited and > published directly from the CMS web interface. If you added the CMS > bookmarklet, in one click, you're on the source of the page, ready to edit > and publish. A few clicks later, the site is staged, then you can publish > it. There is actually a bug in svnpubsub that prevents immediate publish, > infra is working on it, but the workflow is really natural. > It should help everyone to modify the plugins versions, for example, and > publish without great experience from the site publication commands. > > > For the components publication, which is to be done only during the release > process, the wrokflow is totally different. After staging the site locally > during the release, you have to import it into website's production svn [3], > as a versionned component path. > Then edit content/resources/extpaths.txt in the Maven main site svn to add > the relative path and protect the diretory to be removed later on Maven > site edits. > When you're happy with the release, you can change component's unversionned > path to symlink to the actual version. > I did this manually with /ant-tasks which is a symlink to /ant-tasks-2.1.3 > > Having this process will make IMHO the asf-svnpubsub-plugin requirements > even easier than expected: no need to update a svn tree, just import. > > > There is still work to do before activating the solution for the real Maven > site, but the actual result is really good, IMHO, since these 2 workflows > are very intuitive. > Any thoughts? > > Regards, > > Hervé > > > [1] http://maventest.apache.org/ > > [2] http://www.staging.apache.org/dev/cmsadoption.html > > [3] > https://svn.apache.org/repos/infra/websites/production/maventest/content/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
