extpaths.txt operates by saying that everything under the subdirectories named in it is excluded from the CMS and must be manually managed. So what Logging does is have the main site be managed in the CMS. The links in the parent project point to generic project directories that are symlinks. For example, the parent might reference "proper/VFS/2.x " to get to the VFS web site. Then, we could have content/proper be listed in extpaths.txt. Then whenever a new VFS release is done it is uploaded to a directory named content/proper/VFS/vfs-2.n. The 2.x link is then modified to point to the newly uploaded content. Thus you never have to modify the parent (or the CMS) to update a subproject, nor do you need to commit it to any other location in subversion except for the production site which, of course, is managed by subversion.
Ralph On Dec 18, 2012, at 10:56 AM, Matt Benson wrote: > Let me see if I understand. Are you saying, Ralph, that when we have > generated content to expose on the website, we should commit it directly to > the production website svn and mark it in extpaths.txt back in our tree in > mainrepo, basically because that avoids the duplication that is created by > storing the generated content directly in mainrepo when it would only be > copied out anyway? Do I finally grasp the intent of expaths.txt? > > Matt > > > On Tue, Dec 18, 2012 at 12:51 PM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> >> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote: >> >>> 2012/12/18 Ralph Goers <ralph.go...@dslextreme.com>: >>>> I still don't understand why you are committing the subprojects to svn. >> That is not required. Just use stage-deploy to deploy to a local >> directory on your computer, then copy that under where you have the >> production web site checked out and check it in. See >> http://wiki.apache.org/logging/ManagingTheWebSite >>>> >>> As I can see in section "Managing Sub-project Sites" this doc says >>> "Make sure all that is added to svn and commit it." >>> So subsites must be checked in (here I configure this to be done tru a >>> maven plugin and not manually) >>> Infra will be able to use as production web site: >>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or >>> https://svn.apache.org/repos/infra/websites/production/commons/content/ >>> but this one still doesn't exist, I will ping infra on the jira entry >>> for their preference). >> >> Step 6 is referring to checking it in directly to >> https://svn.apache.org/repos/infra/websites/production/logging/content/in >> the subdirectory that is listed in extpaths.txt, not some other >> subversion location. If you look under log4j, for example, you will see a >> directory for each release and a directory that is a symlink to the current >> release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3. >> >>> >>> So if you want sub-project sites available AFAIK this (check in all >>> content) must be done (or I misunderstand something: -)). >>> >>> Makes sense ? >> >> Not really. >> >> Ralph >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
