Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[sebb]

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  wrote:
>
> Hello.
>
> Le ven. 16 avr. 2021 à 20:39, Ralph Goers  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 
> > .
>
> 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 
> > .
>
> 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  wrote:
> > >
> > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  
> > > 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 

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Gilles Sadowski]

Hello.

Le ven. 16 avr. 2021 à 20:39, Ralph Goers  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 
> .

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

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  wrote:
> >
> > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  wrote:
> >>
> >> Hello.
> >>
> >> [Sorry for jumping into the discussion while missing the meaning of
> >> most of what is being said (and cutting it).]
> >
> > In future please start a new thread in such cases.
> >
> >>> [...]
>  So why cause additional work for projects that no longer use the CMS?
> >>>
> >>> I repeat, projects hopped on to the SVN area of the CMS , that is 
> >>> unsupported
> >>> and should not have been allowed to happen, it was a workaround by 
> >>> projects
> >>> undocumented to support mainly javadocs etc from what I gather.
> >>>
> >>> You caused the additional work yourselves in the beginning by not fully 
> >>> removing
> >>> from the CMS and all its infrastructure. Infra wants to clear out that 
> >>> area as part
> >>> of migrating away and provides a new space.
> >>
> >> From what I recollect, each of the "Commons" projects (component) has its
> >> own "trunk" area that is now a "git" repository.
> >> "trunk" contains a sub-directory under SVN named "site-content".[1]
> >> For quite some time now, the only thing I'm doing with this directory is 
> >> along
> >> the following:
> >> $ mvn site site:stage
> >> $ cd site-content
> >> $ rm -rf *
> >> $ cp -r ../target/staging/* .
> >> ["svn add" for added files, "svn del" for removed files...]
> >> $ svn commit
> >> And the web site for that component was updated.
> >>
> >> Is "site-content" being replaced by another location?
> >> Is the consequence that in each component we'll have to
> >> $ svn co https://new_location_of_site_content site-content
> >> ?
> >
> > Yes, that is what Infra want people to do.
> > Effectively to rename
> >
> > https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
> > as
> > https://svn.apache.org/repos/infra/sites/commons/content/proper/commons-math
> >
> >> Could we perhaps take this opportunity to do away with SVN
> >> and "site-content" and have some "mvn" target directly populate
> >> the web site?
> >
> > That would be a good idea, but will likely take more than 30 days to
> > design and test.
> >
> > The Commons website consists of lots of different parts which are
> > separately built.
> >
> > The overall website is served from
> >
> > https://svn.apache.org/repos/infra/websites/production/commons/content/
> >
> > The component sites are committed to the appropriate subtree, so when
> > the whole is checked out it all fits together.
> >
> >> Regards,
> >> Gilles
> >>
> >> [1] This has always seemed like a kludge and has repeatedly
> >> caused issues (some of which have been worked around in the
> >> POM, IIRC).
> >
> > Yes, it is a bit of a kludge, but it was a reasonable solution at the time.
> >
> > There are now more options, so it might be possible to improve things.
> >
> > But this needs some thought and planning to ensure everything fits
> > together, and to ensure it's possible to transition without breaking
> > the website for too long.
> >
> > Who is going to so the work?
> >
> > Can it be done and implemented in the 30 day time limit?
> >
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > 

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Ralph Goers]

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 
.  Each of the subproject has their own 
site such as 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  wrote:
> 
> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  wrote:
>> 
>> Hello.
>> 
>> [Sorry for jumping into the discussion while missing the meaning of
>> most of what is being said (and cutting it).]
> 
> In future please start a new thread in such cases.
> 
>>> [...]
 So why cause additional work for projects that no longer use the CMS?
>>> 
>>> I repeat, projects hopped on to the SVN area of the CMS , that is 
>>> unsupported
>>> and should not have been allowed to happen, it was a workaround by projects
>>> undocumented to support mainly javadocs etc from what I gather.
>>> 
>>> You caused the additional work yourselves in the beginning by not fully 
>>> removing
>>> from the CMS and all its infrastructure. Infra wants to clear out that area 
>>> as part
>>> of migrating away and provides a new space.
>> 
>> From what I recollect, each of the "Commons" projects (component) has its
>> own "trunk" area that is now a "git" repository.
>> "trunk" contains a sub-directory under SVN named "site-content".[1]
>> For quite some time now, the only thing I'm doing with this directory is 
>> along
>> the following:
>> $ mvn site site:stage
>> $ cd site-content
>> $ rm -rf *
>> $ cp -r ../target/staging/* .
>> ["svn add" for added files, "svn del" for removed files...]
>> $ svn commit
>> And the web site for that component was updated.
>> 
>> Is "site-content" being replaced by another location?
>> Is the consequence that in each component we'll have to
>> $ svn co https://new_location_of_site_content site-content
>> ?
> 
> Yes, that is what Infra want people to do.
> Effectively to rename
> 
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
> as
> https://svn.apache.org/repos/infra/sites/commons/content/proper/commons-math
> 
>> Could we perhaps take this opportunity to do away with SVN
>> and "site-content" and have some "mvn" target directly populate
>> the web site?
> 
> That would be a good idea, but will likely take more than 30 days to
> design and test.
> 
> The Commons website consists of lots of different parts which are
> separately built.
> 
> The overall website is served from
> 
> https://svn.apache.org/repos/infra/websites/production/commons/content/
> 
> The component sites are committed to the appropriate subtree, so when
> the whole is checked out it all fits together.
> 
>> Regards,
>> Gilles
>> 
>> [1] This has always seemed like a kludge and has repeatedly
>> caused issues (some of which have been worked around in the
>> POM, IIRC).
> 
> Yes, it is a bit of a kludge, but it was a reasonable solution at the time.
> 
> There are now more options, so it might be possible to improve things.
> 
> But this needs some thought and planning to ensure everything fits
> together, and to ensure it's possible to transition without breaking
> the website for too long.
> 
> Who is going to so the work?
> 
> Can it be done and implemented in the 30 day time limit?
> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Gilles Sadowski]

Hi.

Le ven. 16 avr. 2021 à 15:15, sebb  a écrit :
>
> On Fri, 16 Apr 2021 at 13:40, Gilles Sadowski  wrote:
> >
> > Hi.
> >
> > Le ven. 16 avr. 2021 à 14:28, sebb  a écrit :
> > >
> > > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  
> > > 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jira] [Closed] (STATISTICS-30) Gain Marks in Oracle Certified - 1Z0-997-20 Dumps PDF [2021] - Prepare4test

[Alex Herbert]

On Fri, 16 Apr 2021 at 13:21, Gilles Sadowski  wrote:

> Hello Alex.
>
> Le ven. 16 avr. 2021 à 13:27, Alex Herbert (Jira)  a
> écrit :
> >
> >
> >  [
> https://issues.apache.org/jira/browse/STATISTICS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >
> > Alex Herbert closed STATISTICS-30.
> > --
> > Resolution: Invalid
>
> I believe those should be "deleted".
> [The reason is probably to avoid that they be taken into account
> for some report (e.g. number of issues opened/closed).]
>
> Regards,
> Gilles
>

I was not aware of that option. For reference it is under the 'More' button:

More > Delete

Permanently removes the ticket and all its associated data from JIRA.


> > > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[sebb]

On Fri, 16 Apr 2021 at 13:40, Gilles Sadowski  wrote:
>
> Hi.
>
> Le ven. 16 avr. 2021 à 14:28, sebb  a écrit :
> >
> > On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[Gilles Sadowski]

Hi.

Le ven. 16 avr. 2021 à 14:28, sebb  a écrit :
>
> On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

[sebb]

On Thu, 15 Apr 2021 at 14:41, Gilles Sadowski  wrote:
>
> Hello.
>
> [Sorry for jumping into the discussion while missing the meaning of
> most of what is being said (and cutting it).]

In future please start a new thread in such cases.

> > [...]
> > > So why cause additional work for projects that no longer use the CMS?
> >
> > I repeat, projects hopped on to the SVN area of the CMS , that is 
> > unsupported
> > and should not have been allowed to happen, it was a workaround by projects
> > undocumented to support mainly javadocs etc from what I gather.
> >
> > You caused the additional work yourselves in the beginning by not fully 
> > removing
> > from the CMS and all its infrastructure. Infra wants to clear out that area 
> > as part
> > of migrating away and provides a new space.
>
> From what I recollect, each of the "Commons" projects (component) has its
> own "trunk" area that is now a "git" repository.
> "trunk" contains a sub-directory under SVN named "site-content".[1]
> For quite some time now, the only thing I'm doing with this directory is along
> the following:
>  $ mvn site site:stage
>  $ cd site-content
>  $ rm -rf *
>  $ cp -r ../target/staging/* .
> ["svn add" for added files, "svn del" for removed files...]
>  $ svn commit
> And the web site for that component was updated.
>
> Is "site-content" being replaced by another location?
> Is the consequence that in each component we'll have to
>  $ svn co https://new_location_of_site_content site-content
> ?

Yes, that is what Infra want people to do.
Effectively to rename

https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math
as
https://svn.apache.org/repos/infra/sites/commons/content/proper/commons-math

> Could we perhaps take this opportunity to do away with SVN
> and "site-content" and have some "mvn" target directly populate
> the web site?

That would be a good idea, but will likely take more than 30 days to
design and test.

The Commons website consists of lots of different parts which are
separately built.

The overall website is served from

https://svn.apache.org/repos/infra/websites/production/commons/content/

The component sites are committed to the appropriate subtree, so when
the whole is checked out it all fits together.

> Regards,
> Gilles
>
> [1] This has always seemed like a kludge and has repeatedly
> caused issues (some of which have been worked around in the
> POM, IIRC).

Yes, it is a bit of a kludge, but it was a reasonable solution at the time.

There are now more options, so it might be possible to improve things.

But this needs some thought and planning to ensure everything fits
together, and to ensure it's possible to transition without breaking
the website for too long.

Who is going to so the work?

Can it be done and implemented in the 30 day time limit?

> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: CMS Deprecated. Removal of configs and move to new publishing area

[sebb]

On Thu, 15 Apr 2021 at 12:38, Gavin McDonald  wrote:
>
>
>
> On 2021/04/15 09:10:50, sebb  wrote:
> > On Thu, 15 Apr 2021 at 00:47, sebb  wrote:
> > >
> > > On Wed, 14 Apr 2021 at 16:56, Gavin McDonald  wrote:
> > > >
> > > > Hi Commons devs.
> > > >
> > > > As you know, the CMS is going away, we have been on hardware that could 
> > > > fail at any time, and this really has been dragging on longer than 
> > > > anticipated. So, we are accelerating the removal of any CMS related 
> > > > content.
> > > >
> > > > Previously you indicated that the project was no longer using the CMS. 
> > > > This is true in part, but there are still areas we need to move you off 
> > > > of.
> > > >
> > > > 1. https://cms.apache.org/commons/ - We intend to teardown this site 
> > > > shortly. As you indicate you no longer use the CMS, I see no issue with 
> > > > this.
> > >
> > > Agreed.
> > >
> > > > 2. 
> > > > https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/commons.conf
> > > >  - This refers to cms-site, but does not look like it actually uses the 
> > > > CMS, is this your new site build generation? Just to confirm and I'll 
> > > > leave it as is, or let me know if it is outdated and due for removal
> > >
> > > Yes, it is used to build the top-level Commons site.
> > >
> > > > 3. https://svn.apache.org/repos/infra/websites/production/commons/ and 
> > > > https://svn.apache.org/repos/infra/websites/staging/commons/trunk/ - 
> > > > Both of these are still on what we refer to as the 'SVN area of the 
> > > > CMS'. We have around a dozen projects that I know that have re-worked 
> > > > their non-cms website builds to still use these areas for publishing 
> > > > their sites. It too, is deprecated and going away. We have a 
> > > > replacement SVN area in an adjacent part of the Infra tree.
> > >
> > > > https://svn.apache.org/repos/infra/sites/$project is the new location. 
> > > > We will need to perform an svn move to this new location for you. To 
> > > > allow you to prepare please consider this email as 30 days notice.
> > >
> > > Why are those SVN locations deprecated?
> > >
> > > This will mean a *lot* of work for the Commons project, as most
> > > component POMs have a reference to the URL, and there are probably
> > > other references as well that will need to be changed. There are about
> > > 50 active components, as well as several dormant or sandbox ones
> >
> > Also, the POM changes can only really be done after the SVN tree has been 
> > moved
> > Only planning can be done in advance.
>
> Thats fine, get a branch or local checkout ready to go and let me know when 
> it is
> ready.

No idea what you mean by that.
Note that each component now has its own Git repository, so if you are
referring t
> >
> > Further, any developers with local workspaces will need to update
> > these to the new URL.
>
> Yes
>
> >
> > What are the arrangements for the staging areas?
>
> The CMS supported staging. .asf.yaml over on Git supports staging.
> There is no replacement staging area for the CMS.
>
> Please explain what unsupported staging system you are talking about?

I took your email to imply that both websites/production and
websites/staging were moving to sites/commons, but it was not obvious
how that would work.

So I asked what was happening to the staging SVN tree.

> > Do these go under the individual project site directories, or elsewhere?
> >
> > I accept that the CMS build system has maintenance issues and has to
> > be phased out, but that does not affect all projects.
> > 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.

It was never obvious to me that the use of websites/production and
websites/staging was contingent on use of the CMS.

> You caused the additional work yourselves in the beginning by not fully 
> removing
> from the CMS and all its infrastructure.

At the time I asked for help with migrating to a simple build-bot
build, but there was no feedback from Infra, except to say that
build-bot was still supported.

So I removed the CMS software from commons, and left everything else
as was, as that was the simplest approach that I believed met the
requirements.

Indeed the proposed new location of
https://svn.apache.org/repos/infra/sites/$project did not exist at the
time.

> Infra wants to clear out that area as part of migrating away and provides a 
> new space.

That's the part I disagree with - is it really necessary to rename the
SVN directory?
Would keeping the old tree make Infra's job harder?

It certainly causes issues for Commons.

> >
> > > > Any questions, let me know.
> > >
> > > Is it *really* necessary for the files to be moved?
>
> You have asked this before, yes. If you do not agree with the
> 

Re: [jira] [Closed] (STATISTICS-30) Gain Marks in Oracle Certified - 1Z0-997-20 Dumps PDF [2021] - Prepare4test

[Gilles Sadowski]

Hello Alex.

Le ven. 16 avr. 2021 à 13:27, Alex Herbert (Jira)  a écrit :
>
>
>  [ 
> https://issues.apache.org/jira/browse/STATISTICS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Alex Herbert closed STATISTICS-30.
> --
> Resolution: Invalid

I believe those should be "deleted".
[The reason is probably to avoid that they be taken into account
for some report (e.g. number of issues opened/closed).]

Regards,
Gilles

> > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org