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 (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.220.43 as permitted sender)
Message-ID: <50C659E6.7000802@gmail.com>
Date: Mon, 10 Dec 2012 13:53:42 -0800
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: We will not be able to update our websites...
References: 
 <CAPFNckgJo4uZPojVGm=c9h3v3ngNOVSgEso9Z1UnK8u21wVLjQ@mail.gmail.com>
 <7975537489293865589@unknownmsgid>
 <CAPFNckjqs2wdoaJJ7TOTUoEbVSuqCNJeo28JVuju_pQAZS3dNQ@mail.gmail.com>
 <6739808922857852443@unknownmsgid>
 <CAPFNckgfZrXN8kZRi1Lt1ArapSN6AHP6k4W8_mf1WBLZBAMqow@mail.gmail.com>
 <3EC726FE-8E3B-44C5-9D49-ADD7E7995D5A@dslextreme.com>
 <50C60C93.7070104@gmail.com>
 <AB3E5B8E-BE4B-43EE-B94E-6D4ADB4CA184@dslextreme.com>
 <50C63ABD.1060104@gmail.com> <50C63C3E.7040906@gmail.com>
 <CAE9L6G28XspybPGWDrEvQp5Aszum5fu4xKpPw36zXz_Ui0Ffuw@mail.gmail.com>
 <CFA6D1CF-926B-48A8-B152-551053D2EF11@dslextreme.com>
In-Reply-To: <CFA6D1CF-926B-48A8-B152-551053D2EF11@dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 12/10/12 1:27 PM, Ralph Goers wrote:
> Yes, I think you are missing something fundamental.
>
> If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven.  This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.

Sorry, I don't get it.  Why won't the following work:

0) Grab all of, say p.a.o/www/commons.apache.org
1) check all of that into an svn repo
2) when I want to update, say, math, I generate the content locally,
copy it to the /math subtree and check it in.

I guess this is not "proper" from the maven perspective because it
does not use maven deployment.  No big loss, IMHO.  Am I missing
something else?

Phil

>
> Ralph
>
> On Dec 10, 2012, at 11:49 AM, Matt Benson wrote:
>
>> I don't think there's much percentage in moving to the CMS with a structure
>> like that of Commons.  That said, checking in the whole mess, as Phil
>> suggests, seems perfectly doable and should not preclude updating parts of
>> the tree in quite a similar fashion as how updating a given component's
>> site is done today, except no ssh to mino.  Am I missing something
>> fundamental?
>>
>> Matt
>>
>>
>> On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>
>>> On 12/10/12 11:40 AM, Phil Steitz wrote:
>>>> On 12/10/12 10:50 AM, Ralph Goers wrote:
>>>>> All the sub-sites are hooked off the main site.  I would have no idea
>>> how to migrate anything without migrating the main site first.
>>>> Having now looked at [1], it looks to me like we can solve the
>>>> immediate problem using svn pub-sub.  The docs are not clear and
>>>> they may not allow it, but in theory, we could in fact do this
>>>> incrementally - start an svn repo and move the "mutable" portions
>>>> there incrementally, understanding that only changes to the
>>>> svn-migrated stuff will be propagated.  If infra barfs on that, then
>>>> we just commit the whole mess starting at the top level commons
>>>> site, following the Ant example linked on [1].  Then to make
>>>> changes, we follow the process that has been in place for the main
>>>> ASF site for ages - maintain a local checkout of the generated site,
>>>> re-gen when you want to update and check in.
>>>>
>>>> I know playing with the CMS might be fun and interesting; but a) we
>>>> have no volunteers to do this and b) we do not have time to migrate
>>>> all of the content.
>>>>
>>>> Therefore, I suggest we just follow the Ant route; possibly moving
>>>> incrementally if infra allows that.
>>> Let me modify the proposal to make it simpler and more palatable to
>>> infra:
>>>
>>> Just do like Ant - check in the whole mess.
>>>
>>> Phil
>>>> Phil
>>>>
>>>> [1] http://www.apache.org/dev/project-site.html
>>>>> I suppose it is possible to point to the sub-sites in their current
>>> location but in logging we found it more beneficial to simply copy the
>>> content under the main site in the CMS.
>>>>> Are all the sub-sites built with Maven?  Any that are not could move to
>>> the CMS as part of the main site.
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote:
>>>>>
>>>>>> On 12/10/12 7:55 AM, Ralph Goers wrote:
>>>>>>> That is what we did in logging. Changing it at the end is fairly
>>> easy.  However, we don't have much time for testing.
>>>>>> Do we really have to do it all at once?
>>>>>>
>>>>>> IIUC (which is quite possibly false), the intent here is to get
>>>>>> everyone onto svn pub-sub and kill off the rsync processes from
>>>>>> p.a.o to the live site.  The stake in the ground is that the rsyncs
>>>>>> are going to stop Jan 1.  Do I have that right?
>>>>>>
>>>>>> Why can't we move to svn pub-sub incrementally somehow,
>>>>>> understanding that until individual components move, their sites
>>>>>> will be read-only?  So basically, when you decide to make changes to
>>>>>> a site, you get it set up for svn pub-sub?  Note I am including the
>>>>>> main site in this - i.e., it does not have to "move" until it needs
>>>>>> to be changed.  It would seem to me (again, may be missing something
>>>>>> critical) that we could build the newly definitive source svn repo
>>>>>> incrementally, with publishing always sourced from there, but "old"
>>>>>> directories on the live host remaining until they get clobbered.  In
>>>>>> the worst case, if the live host *must* include only svn-published
>>>>>> files, we could seed the new repo with the "old" content.  But I
>>>>>> don't get why that has to be the case; because if it is, we are in
>>>>>> worse shape than Christian suggests - come Jan 1 we will be dark if
>>>>>> we don't get everything moved to svn pub-sub.
>>>>>>
>>>>>> Sorry if above is naive.  The intent is to avoid a huge amount of
>>>>>> fiddling in a short period of time when quite a few component sites
>>>>>> have not changed and will not change for some time to come.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote:
>>>>>>>
>>>>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory <
>>> garydgregory@gmail.com> wrote:
>>>>>>>>> Well, we have to start somewhere. This is going to be a lot of work,
>>>>>>>>> we have many components, unless you see a short cut.
>>>>>>>> I thought we would create: commons-test.apache.org
>>>>>>>> move all components to there and then make a switch from
>>>>>>>> commons.apache.org to the new site
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <grobmeier@gmail.com>
>>> wrote:
>>>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <
>>> garydgregory@gmail.com> wrote:
>>>>>>>>>>> Bah, let's pick one component and start there and skip a test
>>> site.
>>>>>>>>>> But then there is only one component visible under the new
>>> commons.a.o?
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier <
>>> grobmeier@gmail.com> wrote:
>>>>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra.
>>>>>>>>>>>>
>>>>>>>>>>>> Commons is surely a LOT of work.
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to suggest we act immediately.
>>>>>>>>>>>>
>>>>>>>>>>>> In other terms: let us request a commons-test cms where we can
>>> try things
>>>>>>>>>>>> out and prepare the new sites.
>>>>>>>>>>>>
>>>>>>>>>>>> As Ralph Goers has already mentioned, we have a similar
>>> structure in
>>>>>>>>>>>> logging land (1 main site, several sub sites) which might fit to
>>> Commons
>>>>>>>>>>>> too.
>>>>>>>>>>>>
>>>>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites
>>> are
>>>>>>>>>>>> generated via Maven. The target of this generation is then
>>> copied to
>>>>>>>>>>>> another svn tree from which it will be taken and published.
>>>>>>>>>>>>
>>>>>>>>>>>> Obviously we will have to generate sites for each component
>>> then, which
>>>>>>>>>>>> will be a tough job with x-mas arriving.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>>>> https://www.timeandbill.de
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> http://www.grobmeier.de
>>>>>>>>>> https://www.timeandbill.de
>>>>>>>>>>
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.grobmeier.de
>>>>>>>> https://www.timeandbill.de
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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