They should all be built w/ Maven AFAIK. Matt
On Mon, Dec 10, 2012 at 12:50 PM, Ralph Goers <ralph.go...@dslextreme.com>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. > > 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 > >
