Hello. Le ven. 16 avr. 2021 à 20:39, Ralph Goers <ralph.go...@dslextreme.com> a écrit : > > 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>.
So (IIUC this time), we can get things going by requesting/creating a new "git" repository that would be called "commons-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>. Is this an independent "git" repository? Do we also create those as would be a normal repository? I see that the log4j "components" are under https://github.com/apache/logging-site/tree/master/docs/projects And there is only one file (".asf.yaml") in 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. As noted previously, we seem to use that too in (all?) Commons components $ mvn site But, how does one go from the web files created in the target/site/staging directory, to them being moved (?) to the site repository?[1] Regards, Gilles [1] The "Manage the Git Hosted Web Site" link on https://github.com/apache/logging-site points to https://cwiki.apache.org/confluence > > 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
