On Mon, 26 Apr 2021 at 19:01, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le lun. 26 avr. 2021 à 17:08, Ralph Goers <ralph.go...@dslextreme.com> a > écrit : > > > > See below > > > > > On Apr 18, 2021, at 3:21 PM, sebb <seb...@gmail.com> wrote: > > > > > > On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski <gillese...@gmail.com > > > <mailto:gillese...@gmail.com>> wrote: > > >> > > >> Le dim. 18 avr. 2021 à 15:38, sebb <seb...@gmail.com> a écrit : > > >>> > > >>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory <garydgreg...@gmail.com> > > >>> wrote: > > >>>> > > >>>> Note that git also has its gitlink and sub modules features that we > > >>>> could > > >>>> use here. > > >>> > > >>> Are they easy to use? > > >>> Who is going to design and test the replacement? > > >>> Will such a design really be easier to use? > > >>> There's no point changing the publication strategy if it is not an > > >>> improvement. > > >> > > >> Quoting Ralph Goers: > > >> ---CUT--- > > >> When I release Log4j I rum mvn site followed by "mvn site:stage > > >> -DstagingDirectory=$HOME/log4j” on my laptop. I validate the site > > >> locally and then zip the site, cd to my logging-log4j-site project and > > >> unzip it where I want it to go. > > >> ---CUT--- > > >> > > >> Is that the "publication strategy" which you think is not worth > > >> changing to? > > >> > > >> That's not more complicated than what I do now (mentioned in the > > >> other thread). > > > > > > AFAIK the steps you mention in the other thread can be replaced by: > > > > > > $ mvn clean site-deploy # for single module components > > > OR > > > $ mvn clean site site:stage scm-publish:publish-scm # multi module > > > > > > I'm not sure that the proposed method is no more complicated than the > > > present arrangements. > > > > > > The proposal would be two local workspaces to maintain, and two repos > > > for each component. > > > > > > There's also the issue that most of the poms would likely need > > > changing, and the change would not be as simple as changing a URL. > > > > If you use "mvn site:stage -DstagingDirectory=wherever/my/local/site/is” > > then you don’t need to change the poms. > > > > > > > > As well as setting up all the extra Git branches and/or repos. > > > > > > I don't know if a website can be served from a combination of SVN and > > > Git sources, so the top-level website would need to be converted to > > > Git, and something done about the dormant and sandbox sites - probably > > > would need at least one more Git repo to hold them. > > > > Why wouldn’t the dormant and sandbox sites just be part of the main web > > site? > > > > > > > > The only advantage I can see is that there could be a public staging > > > repo for each site. > > > > > > Is that worth all the extra setup? > > > > > > And who is doing the work? > > > > Well, someone will have to volunteer. > > OK to create the > commons-site > "git" repository?
Are you offering to do the work? BTW, I have found out that it is possible to combine site content from SVN and Git repos in order to create the website checkout. So there is no need to convert to Git. == If there is a desire to use Git for the component websites, I suggest you try creating a couple of branches in the commons-math repository: asf-staging and asf-site. See if it is easy to create the staging site and then commit it to the asf-site branch. I suspect it won't be significantly easier than the current process. However do *not* publish the asf-site branch as that will likely mess up the commons website; this may require Infra involvement to recover things. > Gilles > > --------------------------------------------------------------------- > 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
