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). IIUC, the "zip" step could be skipped altogether by setting the "staginDirectory" directly to be the site reporsitory (?). 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
