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.ste...@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 < >>> garydgreg...@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 <grobme...@gmail.com> >>> wrote: >>>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory < >>> garydgreg...@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 < >>> grobme...@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-unsubscr...@commons.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> http://www.grobmeier.de >>>>>>>>>> https://www.timeandbill.de >>>>>>>>>> >>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>> -- >>>>>>>> http://www.grobmeier.de >>>>>>>> https://www.timeandbill.de >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
