You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2021/04/16 12:27:42 UTC
Redesign of Commons website generation (was: CMS Deprecated. Removal
of configs and move to new publishing area)
On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le ven. 16 avr. 2021 à 15:15, sebb <se...@gmail.com> a écrit :
>
> On Fri, 16 Apr 2021 at 13:40, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hi.
> >
> > Le ven. 16 avr. 2021 à 14:28, sebb <se...@gmail.com> a écrit :
> > >
> > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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?
> > >
> >
> > IMHO, the questions are first targeted at INFRA (hence it was
> > appropriate to discuss in the original thread, if I may add);
>
> IMO it is not on-topic for the original thread.
Then I did not understand the original thread. Sorry.
> > they
> > could perhaps point to a (hopefully easy) solution that will please
> > everyone.
>
> If you want an answer from Infra you will have to raise it with them.
I won't do that since I obviously do not understand what was
being talked about.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Fri, 16 Apr 2021 at 13:40, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> Le ven. 16 avr. 2021 à 14:28, sebb <se...@gmail.com> a écrit :
> >
> > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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?
> >
>
> IMHO, the questions are first targeted at INFRA (hence it was
> appropriate to discuss in the original thread, if I may add);
IMO it is not on-topic for the original thread.
> they
> could perhaps point to a (hopefully easy) solution that will please
> everyone.
If you want an answer from Infra you will have to raise it with them.
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le ven. 16 avr. 2021 à 14:28, sebb <se...@gmail.com> a écrit :
>
> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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?
>
IMHO, the questions are first targeted at INFRA (hence it was
appropriate to discuss in the original thread, if I may add); they
could perhaps point to a (hopefully easy) solution that will please
everyone.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <se...@gmail.com> wrote:
>
> On Fri, 16 Apr 2021 at 19:39, Ralph Goers <ra...@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 <se...@gmail.com> wrote:
>>>
>>> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Fri, 16 Apr 2021 at 19:39, Ralph Goers <ra...@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 <se...@gmail.com> wrote:
> >
> > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
One other think I should add. Although Infra’s pages mention tools that you can use those are just suggestions. As long as you use the .asf.yaml files and place the files in the correct locations in the repos you can use any tooling you want to create the sites. I used JBake because I felt it was pretty close to what we were doing in the CMS, but as long as the site gets converted from its source format (markdown, asciidoc, whatever) into HTML and gets placed into the correct directories you can do anything you want.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
[Not replying to the previously last message in the thread but a
heads-up following Bruno's reminder about ".asf.yaml" and Ralph's
mention of it earlier in this thread.]
Could we start from the bottom-up, i.e. create a git repository for
hosting each component's web site?
Then we can gradually adapt the links of the top-level Commons
site to point to the new locations.
Gilles
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Apr 29, 2021, at 4:49 AM, sebb <se...@gmail.com> wrote:
>
> On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski <gi...@gmail.com> wrote:
>>
>> Le jeu. 29 avr. 2021 à 01:45, sebb <se...@gmail.com> a écrit :
>>>
>>> On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>
>>>> It occurs to me that we *should* create a specific "git" repository
>>>> for holding web site contents; having the "asf-site" and "asf-staging"
>>>> branches in the component's repository is looking for trouble: It will
>>>> be too easy to commit the (generated) web files into "master"
>>>> instead of the appropriate branch. [If allowed (even recommended
>>>> as per the doc) by INFRA, we should not frown upon the increased
>>>> separation of concern (source code vs web site management).]
>>>>
>>>> "Logging" has one repository for the top-level site and a separate
>>>> repository for every component.
>>>> IMO, we should do the same (and copy their ".asf.yaml" layout).
>>>
>>> You are proposing about 50 new Git repos.
>>
>> Only because it seems that the functionality was intended that way.
>
> Not as far as I know; many repos have asf-site and asf-staging
> branches alongside the code.
While that works it means that you have “code” branches and “web site” branches in the
same git repo. While Git certainly won’t care it will likely confuse new contributors for 10 minutes.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Thu, 29 Apr 2021 at 15:37, Alex Herbert <al...@gmail.com> wrote:
>
> On Thu, 29 Apr 2021 at 12:49, sebb <se...@gmail.com> wrote:
>
> > On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski <gi...@gmail.com>
> > wrote:
> > >
> > > Le jeu. 29 avr. 2021 à 01:45, sebb <se...@gmail.com> a écrit :
> > > >
> > > > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gi...@gmail.com>
> > wrote:
> > > > >
> > > > > It occurs to me that we *should* create a specific "git" repository
> > > > > for holding web site contents; having the "asf-site" and
> > "asf-staging"
> > > > > branches in the component's repository is looking for trouble: It
> > will
> > > > > be too easy to commit the (generated) web files into "master"
> > > > > instead of the appropriate branch. [If allowed (even recommended
> > > > > as per the doc) by INFRA, we should not frown upon the increased
> > > > > separation of concern (source code vs web site management).]
> > > > >
> > > > > "Logging" has one repository for the top-level site and a separate
> > > > > repository for every component.
> > > > > IMO, we should do the same (and copy their ".asf.yaml" layout).
> > > >
> > > > You are proposing about 50 new Git repos.
> > >
> > > Only because it seems that the functionality was intended that way.
> >
> > Not as far as I know; many repos have asf-site and asf-staging
> > branches alongside the code.
> >
> > > Also: Having independent repositories seems the safest path for
> > > experimenting mix and match; if the latter works, not all components
> > > will use the new system, or migration can be done gradually.
> >
> > It does not matter whether the branches are in the same or a different
> > repo.
> >
>
> IIUC it does for anyone using 'git clone ...' to get the source code. They
> will be subjected to a download of all the site history. This may become
> significant over time relative to the size of the source.
That's a good point.
Looks like we will have to put up with lots of Git repos if we start
to use Git for the site builds.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Alex Herbert <al...@gmail.com>.
On Thu, 29 Apr 2021 at 12:49, sebb <se...@gmail.com> wrote:
> On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski <gi...@gmail.com>
> wrote:
> >
> > Le jeu. 29 avr. 2021 à 01:45, sebb <se...@gmail.com> a écrit :
> > >
> > > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gi...@gmail.com>
> wrote:
> > > >
> > > > It occurs to me that we *should* create a specific "git" repository
> > > > for holding web site contents; having the "asf-site" and
> "asf-staging"
> > > > branches in the component's repository is looking for trouble: It
> will
> > > > be too easy to commit the (generated) web files into "master"
> > > > instead of the appropriate branch. [If allowed (even recommended
> > > > as per the doc) by INFRA, we should not frown upon the increased
> > > > separation of concern (source code vs web site management).]
> > > >
> > > > "Logging" has one repository for the top-level site and a separate
> > > > repository for every component.
> > > > IMO, we should do the same (and copy their ".asf.yaml" layout).
> > >
> > > You are proposing about 50 new Git repos.
> >
> > Only because it seems that the functionality was intended that way.
>
> Not as far as I know; many repos have asf-site and asf-staging
> branches alongside the code.
>
> > Also: Having independent repositories seems the safest path for
> > experimenting mix and match; if the latter works, not all components
> > will use the new system, or migration can be done gradually.
>
> It does not matter whether the branches are in the same or a different
> repo.
>
IIUC it does for anyone using 'git clone ...' to get the source code. They
will be subjected to a download of all the site history. This may become
significant over time relative to the size of the source.
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le jeu. 29 avr. 2021 à 01:45, sebb <se...@gmail.com> a écrit :
> >
> > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > It occurs to me that we *should* create a specific "git" repository
> > > for holding web site contents; having the "asf-site" and "asf-staging"
> > > branches in the component's repository is looking for trouble: It will
> > > be too easy to commit the (generated) web files into "master"
> > > instead of the appropriate branch. [If allowed (even recommended
> > > as per the doc) by INFRA, we should not frown upon the increased
> > > separation of concern (source code vs web site management).]
> > >
> > > "Logging" has one repository for the top-level site and a separate
> > > repository for every component.
> > > IMO, we should do the same (and copy their ".asf.yaml" layout).
> >
> > You are proposing about 50 new Git repos.
>
> Only because it seems that the functionality was intended that way.
Not as far as I know; many repos have asf-site and asf-staging
branches alongside the code.
> Also: Having independent repositories seems the safest path for
> experimenting mix and match; if the latter works, not all components
> will use the new system, or migration can be done gradually.
It does not matter whether the branches are in the same or a different repo.
> > > Until we make the git switch for the live top-level site, we would indeed
> > > (as you proposed) not have a "publish" section in any of the ".asf.yaml"
> > > files (in any of the repositories); we'd only use the "staging" section
> > > that will make the site accessible at
> > > https://commons.staged.apache.org
> >
> > The top-level site does NOT have to be switched to Git for this to work.
> > As I already wrote we can mix SVN and Git.
>
> I propose this in order to be able to test the *full* solution without
> messing with the current setup, based on what you wrote previously:
> That
> https://commons.staged.apache.org
> would go away. [It's not: It will be used as the staging site through the
> ".asf.yaml" mechanism (cf. doc).]
Sorry, I was wrong about that.
> > But of course the way the website is built needs to be changed to
> > select the individual parts as already described.
> > This means a change to the svnpubsub configuration.
> >
> > > Any objection to creating the following repositories:
> > > commons-site.git
> >
> > -1: it's not needed; we can still use the SVN repo.
> >
> > > commons-math-site.git
> > > ?
> >
> > Fine, but please try (and document) the full process of how to stage
> > the site and how to push the staged site to the asf-site branch.
>
> Practical question: Do we care about getting lots commit messages
> sent to the commits@ ML during the test phase?
> Or should I direct the traffic to some other list (which one?) in the
> meantime
>
> > There's no point converting to Git if that process is more involved
> > than the existing process.
>
> I'm not sure that we mean the same with "the existing process".
> Earlier in the thread, I've described what I do:
>
> $ mvn site site:stage
> $ cd site-content
> $ rm -rf *
> $ cd ../target/staging/
> $ cp -r * ../../site-content
> $ cd ../../site-content
> $ svn status
> [Use some commands to "svn add" all the new files and "svn del"
> to remove all the file that do not exist anymore.]
> $ svn commit
AFAIK that can all be done with 'mvn site:publish' though I could be wrong.
> What I'd like to know is whether the "process" should be different
> with the current setup.
>
> IIUC, the ".asf.yaml" approach is to create a subdirectory for each
> new version of the web site (in sync with versions of the code).
No, subdirectories for each version is independent of the .asf.yaml approach.
> So that the last two steps of the "process" above would just be (within
> a newly created subdirectory).
> $ git add -A
> $ git commit
>
> Gilles
>
> > > > > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Apr 29, 2021, at 3:58 AM, Gilles Sadowski <gi...@gmail.com> wrote:
>
>
>> There's no point converting to Git if that process is more involved
>> than the existing process.
>
> I'm not sure that we mean the same with "the existing process".
> Earlier in the thread, I've described what I do:
>
> $ mvn site site:stage
> $ cd site-content
> $ rm -rf *
> $ cd ../target/staging/
> $ cp -r * ../../site-content
> $ cd ../../site-content
> $ svn status
> [Use some commands to "svn add" all the new files and "svn del"
> to remove all the file that do not exist anymore.]
> $ svn commit
>
> What I'd like to know is whether the "process" should be different
> with the current setup.
>
> IIUC, the ".asf.yaml" approach is to create a subdirectory for each
> new version of the web site (in sync with versions of the code).
That is what Log4j does. It did that even when using CMS/SVN. It is not required nor should it be considered a best practice.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Le jeu. 29 avr. 2021 à 01:45, sebb <se...@gmail.com> a écrit :
>
> On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > It occurs to me that we *should* create a specific "git" repository
> > for holding web site contents; having the "asf-site" and "asf-staging"
> > branches in the component's repository is looking for trouble: It will
> > be too easy to commit the (generated) web files into "master"
> > instead of the appropriate branch. [If allowed (even recommended
> > as per the doc) by INFRA, we should not frown upon the increased
> > separation of concern (source code vs web site management).]
> >
> > "Logging" has one repository for the top-level site and a separate
> > repository for every component.
> > IMO, we should do the same (and copy their ".asf.yaml" layout).
>
> You are proposing about 50 new Git repos.
Only because it seems that the functionality was intended that way.
Also: Having independent repositories seems the safest path for
experimenting mix and match; if the latter works, not all components
will use the new system, or migration can be done gradually.
> > Until we make the git switch for the live top-level site, we would indeed
> > (as you proposed) not have a "publish" section in any of the ".asf.yaml"
> > files (in any of the repositories); we'd only use the "staging" section
> > that will make the site accessible at
> > https://commons.staged.apache.org
>
> The top-level site does NOT have to be switched to Git for this to work.
> As I already wrote we can mix SVN and Git.
I propose this in order to be able to test the *full* solution without
messing with the current setup, based on what you wrote previously:
That
https://commons.staged.apache.org
would go away. [It's not: It will be used as the staging site through the
".asf.yaml" mechanism (cf. doc).]
> But of course the way the website is built needs to be changed to
> select the individual parts as already described.
> This means a change to the svnpubsub configuration.
>
> > Any objection to creating the following repositories:
> > commons-site.git
>
> -1: it's not needed; we can still use the SVN repo.
>
> > commons-math-site.git
> > ?
>
> Fine, but please try (and document) the full process of how to stage
> the site and how to push the staged site to the asf-site branch.
Practical question: Do we care about getting lots commit messages
sent to the commits@ ML during the test phase?
Or should I direct the traffic to some other list (which one?) in the
meantime
> There's no point converting to Git if that process is more involved
> than the existing process.
I'm not sure that we mean the same with "the existing process".
Earlier in the thread, I've described what I do:
$ mvn site site:stage
$ cd site-content
$ rm -rf *
$ cd ../target/staging/
$ cp -r * ../../site-content
$ cd ../../site-content
$ svn status
[Use some commands to "svn add" all the new files and "svn del"
to remove all the file that do not exist anymore.]
$ svn commit
What I'd like to know is whether the "process" should be different
with the current setup.
IIUC, the ".asf.yaml" approach is to create a subdirectory for each
new version of the web site (in sync with versions of the code).
So that the last two steps of the "process" above would just be (within
a newly created subdirectory).
$ git add -A
$ git commit
Gilles
> > > > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gi...@gmail.com> wrote:
>
> It occurs to me that we *should* create a specific "git" repository
> for holding web site contents; having the "asf-site" and "asf-staging"
> branches in the component's repository is looking for trouble: It will
> be too easy to commit the (generated) web files into "master"
> instead of the appropriate branch. [If allowed (even recommended
> as per the doc) by INFRA, we should not frown upon the increased
> separation of concern (source code vs web site management).]
>
> "Logging" has one repository for the top-level site and a separate
> repository for every component.
> IMO, we should do the same (and copy their ".asf.yaml" layout).
You are proposing about 50 new Git repos.
> Until we make the git switch for the live top-level site, we would indeed
> (as you proposed) not have a "publish" section in any of the ".asf.yaml"
> files (in any of the repositories); we'd only use the "staging" section
> that will make the site accessible at
> https://commons.staged.apache.org
The top-level site does NOT have to be switched to Git for this to work.
As I already wrote we can mix SVN and Git.
But of course the way the website is built needs to be changed to
select the individual parts as already described.
This means a change to the svnpubsub configuration.
> Any objection to creating the following repositories:
> commons-site.git
-1: it's not needed; we can still use the SVN repo.
> commons-math-site.git
> ?
Fine, but please try (and document) the full process of how to stage
the site and how to push the staged site to the asf-site branch.
There's no point converting to Git if that process is more involved
than the existing process.
> Gilles
>
>
>
>
> Le mer. 28 avr. 2021 à 00:39, sebb <se...@gmail.com> a écrit :
> >
> > On Tue, 27 Apr 2021 at 17:03, Ralph Goers <ra...@dslextreme.com> wrote:
> > >
> > >
> > >
> > > > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski <gi...@gmail.com> wrote:
> > > >
> > > > Le mar. 27 avr. 2021 à 12:32, sebb <sebbaz@gmail.com <ma...@gmail.com>> a écrit :
> > > >>
> > > >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gi...@gmail.com> wrote:
> > > >>>
> > > >>>>>> [...]
> > > >>>>>
> > > >>>>> OK to create the
> > > >>>>> commons-site
> > > >>>>> "git" repository?
> > > >>>>
> > > >>>> Are you offering to do the work?
> > > >>>
> > > >>> If the option is still on the table, I could test the
> > > >>> website-related feature of ".asf.yaml":
> > > >>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
> > > >>
> > > >> Please do NOT attempt to use the 'publish' feature.
> > > >>
> > > >> As I already wrote that will likely mangle the current website and may
> > > >> require Infa assistance to untangle.
> > > >
> > > > I certainly do not want to do that.
> > > >
> > > >> Removal of a publish entry from .asf.yaml does not undo the checkout,
> > > >> and only Infra have direct access to the TLP server.
> > > >
> > > > Alas, there is a limit to INFRA's magics... ;-)
> > > >
> > > >> However, you could experiment with the 'staging' feature, and see how
> > > >> easy it is to publish the site to the asf-site branch.
> > > >
> > > > I must be missing something because I don't see what there is
> > > > to do then, apart from
> > > > $ git checkout asf-site
> > > > $ mvn site site:stage
> > > >
> > > > And, just as now, the functional (except perhaps for the links to
> > > > the top-level Commons site) static site will be under
> > > > target/staging
> > > >
> > >
> > > ASF git-based web sites use two branches; asf-site for the live site and asf-staging for the
> > > taged site. So when Sebb is telling you to work on the staging site only he means commit
> > > only to the asf-staging branch.
> > >
> > >
> > > >>
> > > >> Just don't attempt to publish that branch.
> > > >>
> > > >>>>
> > > >>>> BTW, I have found out that it is possible to combine site content from
> > > >>>> SVN and Git repos in order to create the website checkout.
> > > >>>> So there is no need to convert to Git.
> > > >>>
> > > >>> Is it the solution straightforwardly applicable to the current
> > > >>> setup of the Commons web site? [So that ".asf.yaml" should
> > > >>> not be used for the projects' sites.]
> > > >>
> > > >> AFAICT, yes.
> > > >>
> > > >> The website is currently taken from:
> > > >>
> > > >> https://svn-master.apache.org/repos/infra/websites/production/commons
> > > >>
> > > >> This is done as a single checkout.
> > > >>
> > > >> This could be changed to take the top-level website from its own
> > > >> location, and the dormant, sandbox and proper trees could be checked
> > > >> out into the relevant subdirectories.
> > > >>
> > > >> This should be fine so long as the top-level site does not have any
> > > >> files in those 3 subdirectories.
> > > >>
> > > >> For an example of this, go to
> > > >> https://infra-reports.apache.org/site-source/
> > > >> and enter 'ant.apache.org' in the search box 'Find a web site'
> > > >>
> > > >> You should see 4 entries at different levels derived from different SVN URLs.
> > > >> Note that in each case the parent SVN tree does not have an entry for
> > > >> its children.
> > > >> E.g. The SVN location for ant.apache.org does not have a directory
> > > >> easyant or ivy.
> > > >>
> > > >> Note that .asf.yaml does not apply to SVN checkouts.
> > > >>
> > > >> If we were to determine that Git was better for the proper websites,
> > > >
> > > > How to do that without a playground for testing?
> > >
> > >
> > > You create a repo that only has an .asf.yaml in the asf-staging branch. Until you
> > > merge the asf-staging branch to the asf-site branch nothing will be live from it as it
> > > will not have an .asf.yaml file.
> >
> > Actually I *am* suggesting to try merging to the asf-site branch.
> > That is needed to explore the full process needed to move to Git
> > (apart from final publication)
> >
> > Of course it is vital that the .asf.yaml file does *not* have a
> > publish entry yet.
> >
> > If Commons does decide that Git is the way to go, at some point the
> > asf.yaml file publish entry can be added.
> > This will have to be carefully co-ordinated with the removal of the
> > existing SVN site to avoid mangling the site.
> >
> > >
> > > Ralph
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
It occurs to me that we *should* create a specific "git" repository
for holding web site contents; having the "asf-site" and "asf-staging"
branches in the component's repository is looking for trouble: It will
be too easy to commit the (generated) web files into "master"
instead of the appropriate branch. [If allowed (even recommended
as per the doc) by INFRA, we should not frown upon the increased
separation of concern (source code vs web site management).]
"Logging" has one repository for the top-level site and a separate
repository for every component.
IMO, we should do the same (and copy their ".asf.yaml" layout).
Until we make the git switch for the live top-level site, we would indeed
(as you proposed) not have a "publish" section in any of the ".asf.yaml"
files (in any of the repositories); we'd only use the "staging" section
that will make the site accessible at
https://commons.staged.apache.org
Any objection to creating the following repositories:
commons-site.git
commons-math-site.git
?
Gilles
Le mer. 28 avr. 2021 à 00:39, sebb <se...@gmail.com> a écrit :
>
> On Tue, 27 Apr 2021 at 17:03, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> >
> >
> > > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski <gi...@gmail.com> wrote:
> > >
> > > Le mar. 27 avr. 2021 à 12:32, sebb <sebbaz@gmail.com <ma...@gmail.com>> a écrit :
> > >>
> > >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gi...@gmail.com> wrote:
> > >>>
> > >>>>>> [...]
> > >>>>>
> > >>>>> OK to create the
> > >>>>> commons-site
> > >>>>> "git" repository?
> > >>>>
> > >>>> Are you offering to do the work?
> > >>>
> > >>> If the option is still on the table, I could test the
> > >>> website-related feature of ".asf.yaml":
> > >>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
> > >>
> > >> Please do NOT attempt to use the 'publish' feature.
> > >>
> > >> As I already wrote that will likely mangle the current website and may
> > >> require Infa assistance to untangle.
> > >
> > > I certainly do not want to do that.
> > >
> > >> Removal of a publish entry from .asf.yaml does not undo the checkout,
> > >> and only Infra have direct access to the TLP server.
> > >
> > > Alas, there is a limit to INFRA's magics... ;-)
> > >
> > >> However, you could experiment with the 'staging' feature, and see how
> > >> easy it is to publish the site to the asf-site branch.
> > >
> > > I must be missing something because I don't see what there is
> > > to do then, apart from
> > > $ git checkout asf-site
> > > $ mvn site site:stage
> > >
> > > And, just as now, the functional (except perhaps for the links to
> > > the top-level Commons site) static site will be under
> > > target/staging
> > >
> >
> > ASF git-based web sites use two branches; asf-site for the live site and asf-staging for the
> > taged site. So when Sebb is telling you to work on the staging site only he means commit
> > only to the asf-staging branch.
> >
> >
> > >>
> > >> Just don't attempt to publish that branch.
> > >>
> > >>>>
> > >>>> BTW, I have found out that it is possible to combine site content from
> > >>>> SVN and Git repos in order to create the website checkout.
> > >>>> So there is no need to convert to Git.
> > >>>
> > >>> Is it the solution straightforwardly applicable to the current
> > >>> setup of the Commons web site? [So that ".asf.yaml" should
> > >>> not be used for the projects' sites.]
> > >>
> > >> AFAICT, yes.
> > >>
> > >> The website is currently taken from:
> > >>
> > >> https://svn-master.apache.org/repos/infra/websites/production/commons
> > >>
> > >> This is done as a single checkout.
> > >>
> > >> This could be changed to take the top-level website from its own
> > >> location, and the dormant, sandbox and proper trees could be checked
> > >> out into the relevant subdirectories.
> > >>
> > >> This should be fine so long as the top-level site does not have any
> > >> files in those 3 subdirectories.
> > >>
> > >> For an example of this, go to
> > >> https://infra-reports.apache.org/site-source/
> > >> and enter 'ant.apache.org' in the search box 'Find a web site'
> > >>
> > >> You should see 4 entries at different levels derived from different SVN URLs.
> > >> Note that in each case the parent SVN tree does not have an entry for
> > >> its children.
> > >> E.g. The SVN location for ant.apache.org does not have a directory
> > >> easyant or ivy.
> > >>
> > >> Note that .asf.yaml does not apply to SVN checkouts.
> > >>
> > >> If we were to determine that Git was better for the proper websites,
> > >
> > > How to do that without a playground for testing?
> >
> >
> > You create a repo that only has an .asf.yaml in the asf-staging branch. Until you
> > merge the asf-staging branch to the asf-site branch nothing will be live from it as it
> > will not have an .asf.yaml file.
>
> Actually I *am* suggesting to try merging to the asf-site branch.
> That is needed to explore the full process needed to move to Git
> (apart from final publication)
>
> Of course it is vital that the .asf.yaml file does *not* have a
> publish entry yet.
>
> If Commons does decide that Git is the way to go, at some point the
> asf.yaml file publish entry can be added.
> This will have to be carefully co-ordinated with the removal of the
> existing SVN site to avoid mangling the site.
>
> >
> > Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Tue, 27 Apr 2021 at 17:03, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
> > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mar. 27 avr. 2021 à 12:32, sebb <sebbaz@gmail.com <ma...@gmail.com>> a écrit :
> >>
> >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gi...@gmail.com> wrote:
> >>>
> >>>>>> [...]
> >>>>>
> >>>>> OK to create the
> >>>>> commons-site
> >>>>> "git" repository?
> >>>>
> >>>> Are you offering to do the work?
> >>>
> >>> If the option is still on the table, I could test the
> >>> website-related feature of ".asf.yaml":
> >>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
> >>
> >> Please do NOT attempt to use the 'publish' feature.
> >>
> >> As I already wrote that will likely mangle the current website and may
> >> require Infa assistance to untangle.
> >
> > I certainly do not want to do that.
> >
> >> Removal of a publish entry from .asf.yaml does not undo the checkout,
> >> and only Infra have direct access to the TLP server.
> >
> > Alas, there is a limit to INFRA's magics... ;-)
> >
> >> However, you could experiment with the 'staging' feature, and see how
> >> easy it is to publish the site to the asf-site branch.
> >
> > I must be missing something because I don't see what there is
> > to do then, apart from
> > $ git checkout asf-site
> > $ mvn site site:stage
> >
> > And, just as now, the functional (except perhaps for the links to
> > the top-level Commons site) static site will be under
> > target/staging
> >
>
> ASF git-based web sites use two branches; asf-site for the live site and asf-staging for the
> taged site. So when Sebb is telling you to work on the staging site only he means commit
> only to the asf-staging branch.
>
>
> >>
> >> Just don't attempt to publish that branch.
> >>
> >>>>
> >>>> BTW, I have found out that it is possible to combine site content from
> >>>> SVN and Git repos in order to create the website checkout.
> >>>> So there is no need to convert to Git.
> >>>
> >>> Is it the solution straightforwardly applicable to the current
> >>> setup of the Commons web site? [So that ".asf.yaml" should
> >>> not be used for the projects' sites.]
> >>
> >> AFAICT, yes.
> >>
> >> The website is currently taken from:
> >>
> >> https://svn-master.apache.org/repos/infra/websites/production/commons
> >>
> >> This is done as a single checkout.
> >>
> >> This could be changed to take the top-level website from its own
> >> location, and the dormant, sandbox and proper trees could be checked
> >> out into the relevant subdirectories.
> >>
> >> This should be fine so long as the top-level site does not have any
> >> files in those 3 subdirectories.
> >>
> >> For an example of this, go to
> >> https://infra-reports.apache.org/site-source/
> >> and enter 'ant.apache.org' in the search box 'Find a web site'
> >>
> >> You should see 4 entries at different levels derived from different SVN URLs.
> >> Note that in each case the parent SVN tree does not have an entry for
> >> its children.
> >> E.g. The SVN location for ant.apache.org does not have a directory
> >> easyant or ivy.
> >>
> >> Note that .asf.yaml does not apply to SVN checkouts.
> >>
> >> If we were to determine that Git was better for the proper websites,
> >
> > How to do that without a playground for testing?
>
>
> You create a repo that only has an .asf.yaml in the asf-staging branch. Until you
> merge the asf-staging branch to the asf-site branch nothing will be live from it as it
> will not have an .asf.yaml file.
Actually I *am* suggesting to try merging to the asf-site branch.
That is needed to explore the full process needed to move to Git
(apart from final publication)
Of course it is vital that the .asf.yaml file does *not* have a
publish entry yet.
If Commons does decide that Git is the way to go, at some point the
asf.yaml file publish entry can be added.
This will have to be carefully co-ordinated with the removal of the
existing SVN site to avoid mangling the site.
>
> Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Apr 27, 2021, at 6:57 AM, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mar. 27 avr. 2021 à 12:32, sebb <sebbaz@gmail.com <ma...@gmail.com>> a écrit :
>>
>> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>>>>> [...]
>>>>>
>>>>> OK to create the
>>>>> commons-site
>>>>> "git" repository?
>>>>
>>>> Are you offering to do the work?
>>>
>>> If the option is still on the table, I could test the
>>> website-related feature of ".asf.yaml":
>>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
>>
>> Please do NOT attempt to use the 'publish' feature.
>>
>> As I already wrote that will likely mangle the current website and may
>> require Infa assistance to untangle.
>
> I certainly do not want to do that.
>
>> Removal of a publish entry from .asf.yaml does not undo the checkout,
>> and only Infra have direct access to the TLP server.
>
> Alas, there is a limit to INFRA's magics... ;-)
>
>> However, you could experiment with the 'staging' feature, and see how
>> easy it is to publish the site to the asf-site branch.
>
> I must be missing something because I don't see what there is
> to do then, apart from
> $ git checkout asf-site
> $ mvn site site:stage
>
> And, just as now, the functional (except perhaps for the links to
> the top-level Commons site) static site will be under
> target/staging
>
ASF git-based web sites use two branches; asf-site for the live site and asf-staging for the
taged site. So when Sebb is telling you to work on the staging site only he means commit
only to the asf-staging branch.
>>
>> Just don't attempt to publish that branch.
>>
>>>>
>>>> BTW, I have found out that it is possible to combine site content from
>>>> SVN and Git repos in order to create the website checkout.
>>>> So there is no need to convert to Git.
>>>
>>> Is it the solution straightforwardly applicable to the current
>>> setup of the Commons web site? [So that ".asf.yaml" should
>>> not be used for the projects' sites.]
>>
>> AFAICT, yes.
>>
>> The website is currently taken from:
>>
>> https://svn-master.apache.org/repos/infra/websites/production/commons
>>
>> This is done as a single checkout.
>>
>> This could be changed to take the top-level website from its own
>> location, and the dormant, sandbox and proper trees could be checked
>> out into the relevant subdirectories.
>>
>> This should be fine so long as the top-level site does not have any
>> files in those 3 subdirectories.
>>
>> For an example of this, go to
>> https://infra-reports.apache.org/site-source/
>> and enter 'ant.apache.org' in the search box 'Find a web site'
>>
>> You should see 4 entries at different levels derived from different SVN URLs.
>> Note that in each case the parent SVN tree does not have an entry for
>> its children.
>> E.g. The SVN location for ant.apache.org does not have a directory
>> easyant or ivy.
>>
>> Note that .asf.yaml does not apply to SVN checkouts.
>>
>> If we were to determine that Git was better for the proper websites,
>
> How to do that without a playground for testing?
You create a repo that only has an .asf.yaml in the asf-staging branch. Until you
merge the asf-staging branch to the asf-site branch nothing will be live from it as it
will not have an .asf.yaml file.
Ralph
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mar. 27 avr. 2021 à 12:32, sebb <se...@gmail.com> a écrit :
>
> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > >>> [...]
> > > >
> > > > OK to create the
> > > > commons-site
> > > > "git" repository?
> > >
> > > Are you offering to do the work?
> >
> > If the option is still on the table, I could test the
> > website-related feature of ".asf.yaml":
> > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
>
> Please do NOT attempt to use the 'publish' feature.
>
> As I already wrote that will likely mangle the current website and may
> require Infa assistance to untangle.
I certainly do not want to do that.
> Removal of a publish entry from .asf.yaml does not undo the checkout,
> and only Infra have direct access to the TLP server.
Alas, there is a limit to INFRA's magics... ;-)
> However, you could experiment with the 'staging' feature, and see how
> easy it is to publish the site to the asf-site branch.
I must be missing something because I don't see what there is
to do then, apart from
$ git checkout asf-site
$ mvn site site:stage
And, just as now, the functional (except perhaps for the links to
the top-level Commons site) static site will be under
target/staging
>
> Just don't attempt to publish that branch.
>
> > >
> > > BTW, I have found out that it is possible to combine site content from
> > > SVN and Git repos in order to create the website checkout.
> > > So there is no need to convert to Git.
> >
> > Is it the solution straightforwardly applicable to the current
> > setup of the Commons web site? [So that ".asf.yaml" should
> > not be used for the projects' sites.]
>
> AFAICT, yes.
>
> The website is currently taken from:
>
> https://svn-master.apache.org/repos/infra/websites/production/commons
>
> This is done as a single checkout.
>
> This could be changed to take the top-level website from its own
> location, and the dormant, sandbox and proper trees could be checked
> out into the relevant subdirectories.
>
> This should be fine so long as the top-level site does not have any
> files in those 3 subdirectories.
>
> For an example of this, go to
> https://infra-reports.apache.org/site-source/
> and enter 'ant.apache.org' in the search box 'Find a web site'
>
> You should see 4 entries at different levels derived from different SVN URLs.
> Note that in each case the parent SVN tree does not have an entry for
> its children.
> E.g. The SVN location for ant.apache.org does not have a directory
> easyant or ivy.
>
> Note that .asf.yaml does not apply to SVN checkouts.
>
> If we were to determine that Git was better for the proper websites,
How to do that without a playground for testing?
> we would need to ensure that the existing site is removed from SVN
> before trying to replace it with one from Git.
That's why we should be able to test the full set of options. Is it
possible to "publish" to some place that would not interfere with
the current setup (and its adapting to INFRA's requirements)?
Could we perhaps use the "subdir" feature (see below the copy/paste
of INFRA's instructions) in order to publish to an alternative page:
https://commons.apache.org
-> current top-level (still using SVN)
https://commons.apache.org/git-site-commons
-> alternative top-level (testing ".asf.yaml", publishing to given "sudir")
https://commons.apache.org/math
-> current site for component (using SVN)
https://commons.apache.org/git-site-math
-> component's alternative site
If the git top-level site is not created yet (due to lack of time or deciding
it's not worth it), links from the alternative site would point to the current
top-level, but that would still allow each component to independently test
(at its own pace) the move to "git".
> > >
> > > ==
> > >
> > > If there is a desire to use Git for the component websites, I suggest
> > > you try creating a couple of branches in the commons-math repository:
> > > asf-staging and asf-site.
> > >
> > > See if it is easy to create the staging site and then commit it to the
> > > asf-site branch.
> >
> > Did I misunderstand that the above documentation assumes a
> > dedicated "git" repository for the web site's contents?
>
> Not sure what documentation you are referring to.
From the link above, here is the part that concerns web sites
publication:
---CUT---
Web Site Deployment Service for Git Repositories
The staging and publish features of the .asf.yaml file in a git
repository manages web site deployment.
NOTE : Web site staging and publishing features are applied using the
repository in which you have specified staging and publishing . Thus,
only specify it within the repository that contains your web site
material, or you could end up just seeing a list of source code files
from your source repository.
Primer
A basic staging and publishing profile to get you started could be:
# Staging and publishing profile for yourproject-website.git:
staging:
profile: ~
whoami: asf-staging
publish:
whoami: asf-site
This configuration enables a staging (live preview) web site at
yourproject.staged.apache.org using the asf-staging branch of your
repository, as well as deploying the asf-site branch of the repository
to your main web site at yourproject.apache.org. Details below:
Staging a web site preview domain
To enable staging (live preview) of your project's web site, add a
staging entry to the site repository's .asf.yaml file.
As an example, take the imaginary yourproject-website.git with an
.asf.yaml file containing the following entry:
staging:
profile: beta
This would stage the current branch at
https://yourproject-beta.staged.apache.org/ . You can add multiple
staging profiles and thus multiple branches staged for preview. This
can be helpful when doing A/B evaluations of website contents and
features.
You can also omit the profile value, and stage directly at
https://yourproject.staged.apache.org/ . ( "~" (tilde) means "no
value" in YAML):
staging:
profile: ~
Preventing branch-override on cloning a branch
Set a protection on multi-tenancy by specifying a whoami setting. If
the setting's value does not match the current branch, no
checkout/update will happen. You can have this in the .asf.yaml file
on the asf-staging branch:
staging:
profile: ~
whoami: asf-staging
When you clone that branch to a new branch like asf-staging-copy, the
staging web site server will notice that the value of whoami does not
match asf-staging-copy, and will ignore that branch until the whoami
is updated to match it.
Publishing a branch to your project web site
Note: if you have previously used gitwcsub for web site publishing,
your first publish action using .asf.yaml will cause any existing
gitwcsub or svnwcsub subscription to stop working. This ensures that
there are no race conditions or "repository fights" going on when you
publish.
To publish a branch to your project web site sub-domain
(yourproject.apache.org), set up a configuration block called publish
in your .asf.yaml file. Enable branch-protection through the whoami
parameter, like so:
publish:
whoami: asf-site
If, for whatever reason, a project wishes to revert back to gitwcsub
for publishing, remove the publish feature in your .asf.yaml file.
Specifying a non-apache.org hostname
By default, web sites will be published at $project.apache.org where
$project is the sub-domain name of your project, as determined by the
repository name.
Some projects have special domains, like openoffice.org, and may
publish to these by specifying a hostname attribute in the publish
configuration block:
publish:
whoami: asf-site
hostname: www.openoffice.org
NOTE: You cannot specify your $project.apache.org hostname with this
setting. It has to be inferred to prevent abuse. Also, please do not
abuse this feature, thanks!
Specifying a sub-directory to publish to
To publish to a sub-directory of the web site URL, specify a subdir
value. Such checkouts can be useful for sub-projects.
For instance, if httpd wished to check out a repository into
httpd.apache.org/subproject, they could use the following
configuration:
publish:
whoami: asf-site
subdir: subproject
CMS/pelican sub-directories for static output
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
---CUT---
>
> But AFAIK it does not matter if there is a separate Git repo with the
> asf-site and asf-staging branches, just as long as they can be
> separately checked out.
Perhaps; however isn't it a step towards more flexibility? [E.g. if
one wants to use alternative tools for generating the HTML files.]
> > Or is this suggested only for an overhaul of how the sites are
> > built? I.e. do we need/want something like
> > https://gitbox.apache.org/repos/asf?p=logging-site.git
> > https://gitbox.apache.org/repos/asf?p=logging-log4j-site.git;a=tree
> > or not?
> >
> > Strangely, there is something there:
> > https://commons.staged.apache.org/
>
> That is part of the CMS, and will be going away.
?
This is part of the setup that uses ".asf.yaml" (cf. doc).
> > >
> > > I suspect it won't be significantly easier than the current process.
> > >
> > > However do *not* publish the asf-site branch as that will likely mess
> > > up the commons website; this may require Infra involvement to recover
> > > things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski <gi...@gmail.com> wrote:
>
> >>> [...]
> > >
> > > OK to create the
> > > commons-site
> > > "git" repository?
> >
> > Are you offering to do the work?
>
> If the option is still on the table, I could test the
> website-related feature of ".asf.yaml":
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
Please do NOT attempt to use the 'publish' feature.
As I already wrote that will likely mangle the current website and may
require Infa assistance to untangle.
Removal of a publish entry from .asf.yaml does not undo the checkout,
and only Infra have direct access to the TLP server.
However, you could experiment with the 'staging' feature, and see how
easy it is to publish the site to the asf-site branch.
Just don't attempt to publish that branch.
> >
> > BTW, I have found out that it is possible to combine site content from
> > SVN and Git repos in order to create the website checkout.
> > So there is no need to convert to Git.
>
> Is it the solution straightforwardly applicable to the current
> setup of the Commons web site? [So that ".asf.yaml" should
> not be used for the projects' sites.]
AFAICT, yes.
The website is currently taken from:
https://svn-master.apache.org/repos/infra/websites/production/commons
This is done as a single checkout.
This could be changed to take the top-level website from its own
location, and the dormant, sandbox and proper trees could be checked
out into the relevant subdirectories.
This should be fine so long as the top-level site does not have any
files in those 3 subdirectories.
For an example of this, go to
https://infra-reports.apache.org/site-source/
and enter 'ant.apache.org' in the search box 'Find a web site'
You should see 4 entries at different levels derived from different SVN URLs.
Note that in each case the parent SVN tree does not have an entry for
its children.
E.g. The SVN location for ant.apache.org does not have a directory
easyant or ivy.
Note that .asf.yaml does not apply to SVN checkouts.
If we were to determine that Git was better for the proper websites,
we would need to ensure that the existing site is removed from SVN
before trying to replace it with one from Git.
> >
> > ==
> >
> > If there is a desire to use Git for the component websites, I suggest
> > you try creating a couple of branches in the commons-math repository:
> > asf-staging and asf-site.
> >
> > See if it is easy to create the staging site and then commit it to the
> > asf-site branch.
>
> Did I misunderstand that the above documentation assumes a
> dedicated "git" repository for the web site's contents?
Not sure what documentation you are referring to.
But AFAIK it does not matter if there is a separate Git repo with the
asf-site and asf-staging branches, just as long as they can be
separately checked out.
> Or is this suggested only for an overhaul of how the sites are
> built? I.e. do we need/want something like
> https://gitbox.apache.org/repos/asf?p=logging-site.git
> https://gitbox.apache.org/repos/asf?p=logging-log4j-site.git;a=tree
> or not?
>
> Strangely, there is something there:
> https://commons.staged.apache.org/
That is part of the CMS, and will be going away.
> >
> > I suspect it won't be significantly easier than the current process.
> >
> > However do *not* publish the asf-site branch as that will likely mess
> > up the commons website; this may require Infra involvement to recover
> > things.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
>>> [...]
> >
> > OK to create the
> > commons-site
> > "git" repository?
>
> Are you offering to do the work?
If the option is still on the table, I could test the
website-related feature of ".asf.yaml":
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-BranchProtection
>
> BTW, I have found out that it is possible to combine site content from
> SVN and Git repos in order to create the website checkout.
> So there is no need to convert to Git.
Is it the solution straightforwardly applicable to the current
setup of the Commons web site? [So that ".asf.yaml" should
not be used for the projects' sites.]
>
> ==
>
> If there is a desire to use Git for the component websites, I suggest
> you try creating a couple of branches in the commons-math repository:
> asf-staging and asf-site.
>
> See if it is easy to create the staging site and then commit it to the
> asf-site branch.
Did I misunderstand that the above documentation assumes a
dedicated "git" repository for the web site's contents?
Or is this suggested only for an overhaul of how the sites are
built? I.e. do we need/want something like
https://gitbox.apache.org/repos/asf?p=logging-site.git
https://gitbox.apache.org/repos/asf?p=logging-log4j-site.git;a=tree
or not?
Strangely, there is something there:
https://commons.staged.apache.org/
>
> I suspect it won't be significantly easier than the current process.
>
> However do *not* publish the asf-site branch as that will likely mess
> up the commons website; this may require Infra involvement to recover
> things.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Mon, 26 Apr 2021 at 19:01, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le lun. 26 avr. 2021 à 17:08, Ralph Goers <ra...@dslextreme.com> a écrit :
> >
> > See below
> >
> > > On Apr 18, 2021, at 3:21 PM, sebb <se...@gmail.com> wrote:
> > >
> > > On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski <gilleseran@gmail.com <ma...@gmail.com>> wrote:
> > >>
> > >> Le dim. 18 avr. 2021 à 15:38, sebb <se...@gmail.com> a écrit :
> > >>>
> > >>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@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).
> > >
> > > AFAIK the steps you mention in the other thread can be replaced by:
> > >
> > > $ mvn clean site-deploy # for single module components
> > > OR
> > > $ mvn clean site site:stage scm-publish:publish-scm # multi module
> > >
> > > I'm not sure that the proposed method is no more complicated than the
> > > present arrangements.
> > >
> > > The proposal would be two local workspaces to maintain, and two repos
> > > for each component.
> > >
> > > There's also the issue that most of the poms would likely need
> > > changing, and the change would not be as simple as changing a URL.
> >
> > If you use "mvn site:stage -DstagingDirectory=wherever/my/local/site/is” then you don’t need to change the poms.
> >
> > >
> > > As well as setting up all the extra Git branches and/or repos.
> > >
> > > I don't know if a website can be served from a combination of SVN and
> > > Git sources, so the top-level website would need to be converted to
> > > Git, and something done about the dormant and sandbox sites - probably
> > > would need at least one more Git repo to hold them.
> >
> > Why wouldn’t the dormant and sandbox sites just be part of the main web site?
> >
> > >
> > > The only advantage I can see is that there could be a public staging
> > > repo for each site.
> > >
> > > Is that worth all the extra setup?
> > >
> > > And who is doing the work?
> >
> > Well, someone will have to volunteer.
>
> OK to create the
> commons-site
> "git" repository?
Are you offering to do the work?
BTW, I have found out that it is possible to combine site content from
SVN and Git repos in order to create the website checkout.
So there is no need to convert to Git.
==
If there is a desire to use Git for the component websites, I suggest
you try creating a couple of branches in the commons-math repository:
asf-staging and asf-site.
See if it is easy to create the staging site and then commit it to the
asf-site branch.
I suspect it won't be significantly easier than the current process.
However do *not* publish the asf-site branch as that will likely mess
up the commons website; this may require Infra involvement to recover
things.
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Le lun. 26 avr. 2021 à 17:08, Ralph Goers <ra...@dslextreme.com> a écrit :
>
> See below
>
> > On Apr 18, 2021, at 3:21 PM, sebb <se...@gmail.com> wrote:
> >
> > On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski <gilleseran@gmail.com <ma...@gmail.com>> wrote:
> >>
> >> Le dim. 18 avr. 2021 à 15:38, sebb <se...@gmail.com> a écrit :
> >>>
> >>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@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).
> >
> > AFAIK the steps you mention in the other thread can be replaced by:
> >
> > $ mvn clean site-deploy # for single module components
> > OR
> > $ mvn clean site site:stage scm-publish:publish-scm # multi module
> >
> > I'm not sure that the proposed method is no more complicated than the
> > present arrangements.
> >
> > The proposal would be two local workspaces to maintain, and two repos
> > for each component.
> >
> > There's also the issue that most of the poms would likely need
> > changing, and the change would not be as simple as changing a URL.
>
> If you use "mvn site:stage -DstagingDirectory=wherever/my/local/site/is” then you don’t need to change the poms.
>
> >
> > As well as setting up all the extra Git branches and/or repos.
> >
> > I don't know if a website can be served from a combination of SVN and
> > Git sources, so the top-level website would need to be converted to
> > Git, and something done about the dormant and sandbox sites - probably
> > would need at least one more Git repo to hold them.
>
> Why wouldn’t the dormant and sandbox sites just be part of the main web site?
>
> >
> > The only advantage I can see is that there could be a public staging
> > repo for each site.
> >
> > Is that worth all the extra setup?
> >
> > And who is doing the work?
>
> Well, someone will have to volunteer.
OK to create the
commons-site
"git" repository?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
See below
> On Apr 18, 2021, at 3:21 PM, sebb <se...@gmail.com> wrote:
>
> On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski <gilleseran@gmail.com <ma...@gmail.com>> wrote:
>>
>> Le dim. 18 avr. 2021 à 15:38, sebb <se...@gmail.com> a écrit :
>>>
>>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@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).
>
> AFAIK the steps you mention in the other thread can be replaced by:
>
> $ mvn clean site-deploy # for single module components
> OR
> $ mvn clean site site:stage scm-publish:publish-scm # multi module
>
> I'm not sure that the proposed method is no more complicated than the
> present arrangements.
>
> The proposal would be two local workspaces to maintain, and two repos
> for each component.
>
> There's also the issue that most of the poms would likely need
> changing, and the change would not be as simple as changing a URL.
If you use "mvn site:stage -DstagingDirectory=wherever/my/local/site/is” then you don’t need to change the poms.
>
> As well as setting up all the extra Git branches and/or repos.
>
> I don't know if a website can be served from a combination of SVN and
> Git sources, so the top-level website would need to be converted to
> Git, and something done about the dormant and sandbox sites - probably
> would need at least one more Git repo to hold them.
Why wouldn’t the dormant and sandbox sites just be part of the main web site?
>
> The only advantage I can see is that there could be a public staging
> repo for each site.
>
> Is that worth all the extra setup?
>
> And who is doing the work?
Well, someone will have to volunteer.
Ralph
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le dim. 18 avr. 2021 à 15:38, sebb <se...@gmail.com> a écrit :
> >
> > On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@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).
AFAIK the steps you mention in the other thread can be replaced by:
$ mvn clean site-deploy # for single module components
OR
$ mvn clean site site:stage scm-publish:publish-scm # multi module
I'm not sure that the proposed method is no more complicated than the
present arrangements.
The proposal would be two local workspaces to maintain, and two repos
for each component.
There's also the issue that most of the poms would likely need
changing, and the change would not be as simple as changing a URL.
As well as setting up all the extra Git branches and/or repos.
I don't know if a website can be served from a combination of SVN and
Git sources, so the top-level website would need to be converted to
Git, and something done about the dormant and sandbox sites - probably
would need at least one more Git repo to hold them.
The only advantage I can see is that there could be a public staging
repo for each site.
Is that worth all the extra setup?
And who is doing the work?
> IIUC, the "zip" step could be skipped altogether by setting the
> "staginDirectory" directly to be the site reporsitory (?).
Yes, but that is a minor issue.
> 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 <gi...@gmail.com> wrote:
> > >
> > > > Le dim. 18 avr. 2021 à 12:51, sebb <se...@gmail.com> a écrit :
> > > > >
> > > > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ra...@dslextreme.com>
> > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
> > > > > > >
> > > > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> > > > ralph.goers@dslextreme.com <ma...@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Le dim. 18 avr. 2021 à 15:38, sebb <se...@gmail.com> a écrit :
>
> On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@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 <gi...@gmail.com> wrote:
> >
> > > Le dim. 18 avr. 2021 à 12:51, sebb <se...@gmail.com> a écrit :
> > > >
> > > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ra...@dslextreme.com>
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
> > > > > >
> > > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> > > ralph.goers@dslextreme.com <ma...@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Apr 18, 2021, at 6:38 AM, sebb <se...@gmail.com> wrote:
>
> On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Note that git also has its gitlink and sub modules features that we could
>> use here.
>
> Are they easy to use?
Submodules are documented at https://git-scm.com/book/en/v2/Git-Tools-Submodules. It is a pretty short read. In a sense it is a replacement for the .asf.yaml in the submodules. Every sub-project would still likely have its own repo but you could get them all just by cloning the parent repo with some extra flags on the clone. When you commit changes to the sub-module they still go back to the individual repos, not the parent.
> 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.
Unfortunately, I can’t answer that. I don’t recall ever updating any of the Commons web sites.
>
> 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.
Having gone through a similar process and after reviewing http://commons.apache.org/site-publish.html I’d have to say that the effort isn’t really much different. Logging Services hasn’t implemented any automation around publishing to the main site as Commons seems to do, but it certainly wouldn’t be hard to create a GitHub action to do it.
The main difference I see is that the current commons process seems to deploy directly to the live site. With Git all your commits should go to the ash-staging branch and the automation should be building that. Making it go live is as simple as:
git checkout asf-site
git rebase asf-staging
git push
This allows you to validate the site before it goes live.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Sun, 18 Apr 2021 at 13:40, Gary Gregory <ga...@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.
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 <gi...@gmail.com> wrote:
>
> > Le dim. 18 avr. 2021 à 12:51, sebb <se...@gmail.com> a écrit :
> > >
> > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> > > >
> > > >
> > > >
> > > > > On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
> > > > >
> > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> > ralph.goers@dslextreme.com <ma...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gary Gregory <ga...@gmail.com>.
Note that git also has its gitlink and sub modules features that we could
use here.
Gary
On Sun, Apr 18, 2021, 08:27 Gilles Sadowski <gi...@gmail.com> wrote:
> Le dim. 18 avr. 2021 à 12:51, sebb <se...@gmail.com> a écrit :
> >
> > On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ra...@dslextreme.com>
> wrote:
> > >
> > >
> > >
> > > > On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
> > > >
> > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> ralph.goers@dslextreme.com <ma...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Le dim. 18 avr. 2021 à 12:51, sebb <se...@gmail.com> a écrit :
>
> On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> >
> >
> > > On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
> > >
> > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <ralph.goers@dslextreme.com <ma...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Sun, 18 Apr 2021 at 00:03, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
> > On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
> >
> > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <ralph.goers@dslextreme.com <ma...@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?
Also, the dormant and snapshot components are still in SVN, so we need
to allow for that.
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Apr 17, 2021, at 3:32 PM, sebb <se...@gmail.com> wrote:
>
> On Sat, 17 Apr 2021 at 22:57, Ralph Goers <ralph.goers@dslextreme.com <ma...@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.
Hopefully the information I’ve provided about how the git-based site support with .asf.yaml files will be helpful. 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.
Ralph
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
On Sat, 17 Apr 2021 at 22:57, Ralph Goers <ra...@dslextreme.com> wrote:
>
> You should see my other message but I will reply to your questions also.
>
> > On Apr 16, 2021, at 1:37 PM, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hello.
> >
> > Le ven. 16 avr. 2021 à 20:39, Ralph Goers <ra...@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"?
>
> You could either put everything under commons-site, host just the main site there and put the sub-projects in their own repos, host the main site and some of the sub-projects there with others in their own repos, or almost any other combination you want to dream up.
>
>
> >
> >> 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?
>
> Yes, use the standard tool to create the repos. Infra isn’t involved.
>
> >
> > 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
>
> The default directory is probably master. Nothing actually happens there. The asf-site branch is where the live site is hosted and the asf-staging branch is where the staging site is hosted.
>
> >
> >> 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]
>
> 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.
> If you look at https://github.com/apache/logging-log4j-site/tree/asf-staging <https://github.com/apache/logging-log4j-site/tree/asf-staging> you will notice that every release of log4j has its own web site in its own directory. This allows anyone to go and look at any past release of the web site.
> But if you only want to publish the current version of the site you can just overlay the previous version or set the stagingDirectory location to where the particular site is on your laptop.
>
>
> >
> > 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
>
> Thanks, I will fix that.
>
> Ralph
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
You should see my other message but I will reply to your questions also.
> On Apr 16, 2021, at 1:37 PM, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hello.
>
> Le ven. 16 avr. 2021 à 20:39, Ralph Goers <ra...@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"?
You could either put everything under commons-site, host just the main site there and put the sub-projects in their own repos, host the main site and some of the sub-projects there with others in their own repos, or almost any other combination you want to dream up.
>
>> 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?
Yes, use the standard tool to create the repos. Infra isn’t involved.
>
> 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
The default directory is probably master. Nothing actually happens there. The asf-site branch is where the live site is hosted and the asf-staging branch is where the staging site is hosted.
>
>> 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]
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.
If you look at https://github.com/apache/logging-log4j-site/tree/asf-staging <https://github.com/apache/logging-log4j-site/tree/asf-staging> you will notice that every release of log4j has its own web site in its own directory. This allows anyone to go and look at any past release of the web site.
But if you only want to publish the current version of the site you can just overlay the previous version or set the stagingDirectory location to where the particular site is on your laptop.
>
> 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
Thanks, I will fix that.
Ralph
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by sebb <se...@gmail.com>.
Logging has 10 subprojects, but Commons has over 100 components if you
include dormant and sandbox.
So it will be a major effort to convert all of these.
Can the component sites be converted individually?
On Fri, 16 Apr 2021 at 21:38, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hello.
>
> Le ven. 16 avr. 2021 à 20:39, Ralph Goers <ra...@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 <se...@gmail.com> wrote:
> > >
> > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le ven. 16 avr. 2021 à 20:39, Ralph Goers <ra...@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 <se...@gmail.com> wrote:
> >
> > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Redesign of Commons website generation (was: CMS Deprecated.
Removal of configs and move to new publishing area)
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <se...@gmail.com> wrote:
>
> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski <gi...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>