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.
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 > >
