Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.219.53 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: We will not be able to update our websites...
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: 
 <CAE9L6G0yU4AYfGVvW8g3kV4fvb2T7f_dJFW_tRzTwE1sK01r0Q@mail.gmail.com>
Date: Tue, 18 Dec 2012 11:07:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A1E848B-FAA8-4DAA-9891-FEBA6BBC87CC@dslextreme.com>
References: 
 <CAE9L6G28XspybPGWDrEvQp5Aszum5fu4xKpPw36zXz_Ui0Ffuw@mail.gmail.com>
 <CAE9L6G2eeYa0v-86gL-XAxVpWhFJo-SJHrZeAtqveRTDE=kDAQ@mail.gmail.com>
 <20121214214054.GF20488@dusk.harfang.homelinux.org>
 <CAE9L6G0DxhweWVaDkkRUdJ_mNAp+oAtC9k_9xT+J4MFXKtUT3w@mail.gmail.com>
 <20121214220725.GH20488@dusk.harfang.homelinux.org>
 <CAE9L6G3ZvgC4kH9Nd-nmqKxyC4dNg9mH7ZNWMnb5tvn_Vdma2w@mail.gmail.com>
 <CAPoyBqSWnRbdbmF9-rG_iGDcEh9iomV+-_kNG=imx1D+3nSzqA@mail.gmail.com>
 <CAE9L6G1ZjMwG09C8MLwAFMhNQ_bHgPRukbN7qroxxg+ZuTjVqA@mail.gmail.com>
 <CAPoyBqTGn3d-NgqMOh6e4XwkTaoRLpF288tMF5prU6K0sSAtJQ@mail.gmail.com>
 <CAPoyBqTV9dxKwb24Muzfnwvh+HL6GwuA5RfrBDzUGPp62Q1SHg@mail.gmail.com>
 <27696813-A824-48B0-B8D2-A4890E492574@dslextreme.com>
 <1DA172AB-7EBA-4D82-8267-AD9CB4B0530E@dslextreme.com>
 <CAPoyBqQp1cEF0feOF2ns9fzogXNr0vuxjMzMhf=Qz-FU48Q2qQ@mail.gmail.com>
 <CAPoyBqRwGdKk=OZtXPbo7mV5JsuaMiuNo9YZva_tg0k5x6RO=w@mail.gmail.com>
 <CAPoyBqR_Q93ikaCmKcs4XKNSqw_gfQvBxTwj6NNLChCPieBi5Q@mail.gmail.com>
 <CAPoyBqQNR8P+b
 3xNM-kLvFoq9WAV9-y8dzUXY3wrMLP87zcNqQ@mail.gmail.com>
 <2CED3B63-FFFB-4E31-B0F7-A0CE6965CC15@dslextreme.com>
 <CAPoyBqQeT1Jx3QgJkqLpM9Zj2zu4Ge-Xs4PXYUer4AbBfLv8sQ@mail.gmail.com>
 <88030D83-4CEF-40F6-BA85-1E83664C57B7@dslextreme.com>
 <CAE9L6G0yU4AYfGVvW8g3kV4fvb2T7f_dJFW_tRzTwE1sK01r0Q@mail.gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>,
 gudnabrsam@gmail.com

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?
>=20
> Matt
>=20
>=20
> On Tue, Dec 18, 2012 at 12:51 PM, Ralph Goers =
<ralph.goers@dslextreme.com>wrote:
>=20
>>=20
>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>=20
>>> 2012/12/18 Ralph Goers <ralph.goers@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
>>>>=20
>>> 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).
>>=20
>> 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.
>>=20
>>>=20
>>> So if you want sub-project sites available AFAIK this (check in all
>>> content) must be done (or I misunderstand something: -)).
>>>=20
>>> Makes sense ?
>>=20
>> Not really.
>>=20
>> Ralph
>>=20
>>=20
>>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org