On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski <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. 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. 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? > IIUC, the "zip" step could be skipped altogether by setting the > "staginDirectory" directly to be the site reporsitory (?). Yes, but that is a minor issue. > Gilles > > > We do at least have a way forward if Infra insist on removing > > websites/production. > > Simple to implement, but tedious, as nearly every proper component POM > > will need updating, and existing checkouts will need replacing. > > At least it's a one-off change, and it won't change processes, except > > perhaps for the top-level site. > > > > > > > Gary > > > > > > > > > On Sun, Apr 18, 2021, 08:27 Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > > > Le dim. 18 avr. 2021 à 12:51, sebb <seb...@gmail.com> a écrit : > > > > > > > > > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ralph.go...@dslextreme.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Apr 17, 2021, at 3:32 PM, sebb <seb...@gmail.com> wrote: > > > > > > > > > > > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers < > > > > ralph.go...@dslextreme.com <mailto:ralph.go...@dslextreme.com>> wrote: > > > > > > >> > > > > > > >> > > > > > > >> 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. > > > > > > > > > > > > > > In the Wiki that process is described as follows: > > > > > > > > > > > > > > "3. Add the new site under the content directory (or a > > > > > > > subdirectory > > > > of > > > > > > > that as appropriate)." > > > > > > > > > > > > > > This leaves out all the detail, making it seem simpler than it is. > > > > > > > > > > > > > > We don't have to do that zip dance currently, because the > > > > > > > site-content/ directory is checked out in the workspace. > > > > > > > So the site can be built directly into the target. > > > > > > > > > > > > Yes, a bit more explanation certainly would be helpful. I didn’t > > > > understand it either when I read it until I looked at the .asf.yaml > > > > files > > > > in the subproject. > > > > > > > > > > > > Yes, if you want to build the site directly into the target that > > > > shouldn’t be a problem. > > > > > > > > > > Maybe, but Git is less flexible when it comes to partial checkouts. > > > > > > > > > > > Hopefully the information I’ve provided about how the git-based site > > > > support with .asf.yaml files will be helpful. > > > > > > > > > > I'm not sure it will simplify matters for Commons, given the number of > > > > > components that it has. > > > > > Do we really want to set up -site repos for 50+ components? > > > > > > > > How about > > > > * 1 repository for "proper" > > > > * 1 repository for "sandbox" > > > > * 1 repository for "dormant" > > > > ? > > > > > > > > > Also, the dormant and snapshot components are still in SVN, so we need > > > > > to allow for that. > > > > > > > > What do you mean by "snapshot component"? > > > > > > > > > > > > > > > I had to spend quite a bit of time figuring all this out on my own > > > > > > as > > > > the documents I linked to are even less clear than the Logging > > > > confluence > > > > page. > > > > > > > > > > .asf.yaml is quite neat, but there are a lot of possibilities for > > > > > confusion and error, especially if we end up with many more repos. > > > > > > > > > > > Ralph > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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
