Yes, I see there are pieces of missing information.
When I was doing the work I referred to a couple of Infra web pages to figure
out how things worked. The links are below. In particular, see "Specifying a
sub-directory to publish to” in the second link.
The .asf.yaml file is the key. The subdir field identifies where the sub-site
should appear in the directory structure of the web site. Basically, you
should consider that your web site is going to occupy a single directory
structure wherever the web sites are hosted from. The subdir attribute directs
the tooling as to where each repo should be copied when a commit is performed.
This means that you can break the web site into as few or as many repos as you
want. The commons-site repo would host the basic shell of the site.
If you look at the logging-site repo you will see that it has a source
directory and a content directory. The source directory contains the editable
content. After editing maven is used to convert the content to html and copy
it to the content directory. The content directory is where the web tooling
will pull the website from.
The ask.yaml link says:
The staging and deployment servers support both the content/ sub-dir
and the pelican build output/ sub-dir as the root directory for the web site.
Thus, the website root can be any of:
• The root of the git branch
• The content/ directory at the root of the branch
• The output/ directory at the root of the branch
If you choose the root directory then it would be difficult to host the web
site source in the same repo. So for the logging project I went with the
content directory. However, since all the subprojects are built from the
individual projects using the Maven site plugin, they all use the root
directory.
Hopefully, that helps explain how it works a little better.
Ralph
[1]
https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
[2] https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
> On Apr 17, 2021, at 6:48 AM, sebb <seb...@gmail.com> wrote:
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
