On Fri, 16 Apr 2021 at 19:39, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > FYI - I did the work of moving Logging Services site from the CMS to git. It > really wasn’t that hard. The main web site is at > https://github.com/apache/logging-site > <https://github.com/apache/logging-site>. Each of the subproject has their > own site such as https://github.com/apache/logging-log4j-site > <https://github.com/apache/logging-log4j-site>. Although the Logging Services > site is small the Log4j site is very large. I can tell you that publishing > the web site for each new releases is order of magnitudes faster than SVN > was. I did have to modify how the logging services site gets built but all > the subprojects use the Maven site plugin.
AFAICT, the logging-*-site repos are only used for staging and publication of the website. It looks like the sites are built elsewhere, and then copied into the appropriate repo. The process seems to be described here [1]. However the critical step is: "3. Add the new site under the content directory (or a subdirectory of that as appropriate)." This is not explained. [1] https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites > Ralph > > > > > On Apr 16, 2021, at 5:27 AM, sebb <seb...@gmail.com> wrote: > > > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gillese...@gmail.com> wrote: > >> > >> Hello. > >> > >> [Sorry for jumping into the discussion while missing the meaning of > >> most of what is being said (and cutting it).] > > > > In future please start a new thread in such cases. > > > >>> [...] > >>>> So why cause additional work for projects that no longer use the CMS? > >>> > >>> I repeat, projects hopped on to the SVN area of the CMS , that is > >>> unsupported > >>> and should not have been allowed to happen, it was a workaround by > >>> projects > >>> undocumented to support mainly javadocs etc from what I gather. > >>> > >>> You caused the additional work yourselves in the beginning by not fully > >>> removing > >>> from the CMS and all its infrastructure. Infra wants to clear out that > >>> area as part > >>> of migrating away and provides a new space. > >> > >> From what I recollect, each of the "Commons" projects (component) has its > >> own "trunk" area that is now a "git" repository. > >> "trunk" contains a sub-directory under SVN named "site-content".[1] > >> For quite some time now, the only thing I'm doing with this directory is > >> along > >> the following: > >> $ mvn site site:stage > >> $ cd site-content > >> $ rm -rf * > >> $ cp -r ../target/staging/* . > >> ["svn add" for added files, "svn del" for removed files...] > >> $ svn commit > >> And the web site for that component was updated. > >> > >> Is "site-content" being replaced by another location? > >> Is the consequence that in each component we'll have to > >> $ svn co https://new_location_of_site_content site-content > >> ? > > > > Yes, that is what Infra want people to do. > > Effectively to rename > > > > https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math > > as > > https://svn.apache.org/repos/infra/sites/commons/content/proper/commons-math > > > >> Could we perhaps take this opportunity to do away with SVN > >> and "site-content" and have some "mvn" target directly populate > >> the web site? > > > > That would be a good idea, but will likely take more than 30 days to > > design and test. > > > > The Commons website consists of lots of different parts which are > > separately built. > > > > The overall website is served from > > > > https://svn.apache.org/repos/infra/websites/production/commons/content/ > > > > The component sites are committed to the appropriate subtree, so when > > the whole is checked out it all fits together. > > > >> Regards, > >> Gilles > >> > >> [1] This has always seemed like a kludge and has repeatedly > >> caused issues (some of which have been worked around in the > >> POM, IIRC). > > > > Yes, it is a bit of a kludge, but it was a reasonable solution at the time. > > > > There are now more options, so it might be possible to improve things. > > > > But this needs some thought and planning to ensure everything fits > > together, and to ensure it's possible to transition without breaking > > the website for too long. > > > > Who is going to so the work? > > > > Can it be done and implemented in the 30 day time limit? > > > >> --------------------------------------------------------------------- > >> 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
