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

2021-04-29 Thread sebb
On Thu, 29 Apr 2021 at 15:37, Alex Herbert  wrote:
>
> On Thu, 29 Apr 2021 at 12:49, sebb  wrote:
>
> > On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski 
> > wrote:
> > >
> > > Le jeu. 29 avr. 2021 à 01:45, sebb  a écrit :
> > > >
> > > > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski 
> > 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-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)

2021-04-29 Thread Ralph Goers



> On Apr 29, 2021, at 4:49 AM, sebb  wrote:
> 
> On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski  wrote:
>> 
>> Le jeu. 29 avr. 2021 à 01:45, sebb  a écrit :
>>> 
>>> On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski  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-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)

2021-04-29 Thread Ralph Goers



> On Apr 29, 2021, at 3:58 AM, Gilles Sadowski  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-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)

2021-04-29 Thread Alex Herbert
On Thu, 29 Apr 2021 at 12:49, sebb  wrote:

> On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski 
> wrote:
> >
> > Le jeu. 29 avr. 2021 à 01:45, sebb  a écrit :
> > >
> > > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski 
> 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)

2021-04-29 Thread sebb
On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski  wrote:
>
> Le jeu. 29 avr. 2021 à 01:45, sebb  a écrit :
> >
> > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski  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-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)

2021-04-29 Thread Gilles Sadowski
Le jeu. 29 avr. 2021 à 01:45, sebb  a écrit :
>
> On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski  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-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)

2021-04-28 Thread sebb
On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski  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  a écrit :
> >
> > On Tue, 27 Apr 2021 at 17:03, Ralph Goers  
> > wrote:
> > >
> > >
> > >
> > > > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski  
> > > > wrote:
> > > >
> > > > Le mar. 27 avr. 2021 à 12:32, sebb  > > > > a écrit :
> > > >>
> > > >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  
> > > >> 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.apach

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

2021-04-28 Thread Gilles Sadowski
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  a écrit :
>
> On Tue, 27 Apr 2021 at 17:03, Ralph Goers  wrote:
> >
> >
> >
> > > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski  wrote:
> > >
> > > Le mar. 27 avr. 2021 à 12:32, sebb  > > > a écrit :
> > >>
> > >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  
> > >> 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
>

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

2021-04-27 Thread sebb
On Tue, 27 Apr 2021 at 17:03, Ralph Goers  wrote:
>
>
>
> > On Apr 27, 2021, at 6:57 AM, Gilles Sadowski  wrote:
> >
> > Le mar. 27 avr. 2021 à 12:32, sebb  > > a écrit :
> >>
> >> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  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-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)

2021-04-27 Thread Ralph Goers


> On Apr 27, 2021, at 6:57 AM, Gilles Sadowski  wrote:
> 
> Le mar. 27 avr. 2021 à 12:32, sebb  > a écrit :
>> 
>> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  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)

2021-04-27 Thread Gilles Sadowski
Le mar. 27 avr. 2021 à 12:32, sebb  a écrit :
>
> On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  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: 

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

2021-04-27 Thread sebb
On Tue, 27 Apr 2021 at 02:10, Gilles Sadowski  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-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)

2021-04-26 Thread Gilles Sadowski
>>> [...]
> >
> > 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-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)

2021-04-26 Thread sebb
On Mon, 26 Apr 2021 at 19:01, Gilles Sadowski  wrote:
>
> Le lun. 26 avr. 2021 à 17:08, Ralph Goers  a 
> écrit :
> >
> > See below
> >
> > > On Apr 18, 2021, at 3:21 PM, sebb  wrote:
> > >
> > > On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski  > > > wrote:
> > >>
> > >> Le dim. 18 avr. 2021 à 15:38, sebb  a écrit :
> > >>>
> > >>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  
> > >>> 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-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)

2021-04-26 Thread Gilles Sadowski
Le lun. 26 avr. 2021 à 17:08, Ralph Goers  a écrit :
>
> See below
>
> > On Apr 18, 2021, at 3:21 PM, sebb  wrote:
> >
> > On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski  > > wrote:
> >>
> >> Le dim. 18 avr. 2021 à 15:38, sebb  a écrit :
> >>>
> >>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  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-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)

2021-04-26 Thread Ralph Goers
See below

> On Apr 18, 2021, at 3:21 PM, sebb  wrote:
> 
> On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski  > wrote:
>> 
>> Le dim. 18 avr. 2021 à 15:38, sebb  a écrit :
>>> 
>>> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  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)

2021-04-26 Thread Gilles Sadowski
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-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)

2021-04-18 Thread sebb
On Sun, 18 Apr 2021 at 18:40, Gilles Sadowski  wrote:
>
> Le dim. 18 avr. 2021 à 15:38, sebb  a écrit :
> >
> > On Sun, 18 Apr 2021 at 13:40, Gary Gregory  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  wrote:
> > >
> > > > Le dim. 18 avr. 2021 à 12:51, sebb  a écrit :
> > > > >
> > > > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers 
> > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> > > > > > >
> > > > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> > > > ralph.go...@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 documen

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

2021-04-18 Thread Gilles Sadowski
Le dim. 18 avr. 2021 à 15:38, sebb  a écrit :
>
> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  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  wrote:
> >
> > > Le dim. 18 avr. 2021 à 12:51, sebb  a écrit :
> > > >
> > > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers 
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> > > > > >
> > > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> > > ralph.go...@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-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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



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

2021-04-18 Thread Ralph Goers



> On Apr 18, 2021, at 6:38 AM, sebb  wrote:
> 
> On Sun, 18 Apr 2021 at 13:40, Gary Gregory  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-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)

2021-04-18 Thread sebb
On Sun, 18 Apr 2021 at 13:40, Gary Gregory  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  wrote:
>
> > Le dim. 18 avr. 2021 à 12:51, sebb  a écrit :
> > >
> > > On Sun, 18 Apr 2021 at 00:03, Ralph Goers 
> > wrote:
> > > >
> > > >
> > > >
> > > > > On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> > > > >
> > > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> > ralph.go...@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-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)

2021-04-18 Thread Gary Gregory
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  wrote:

> Le dim. 18 avr. 2021 à 12:51, sebb  a écrit :
> >
> > On Sun, 18 Apr 2021 at 00:03, Ralph Goers 
> wrote:
> > >
> > >
> > >
> > > > On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> > > >
> > > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers <
> ralph.go...@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-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)

2021-04-18 Thread Gilles Sadowski
Le dim. 18 avr. 2021 à 12:51, sebb  a écrit :
>
> On Sun, 18 Apr 2021 at 00:03, Ralph Goers  wrote:
> >
> >
> >
> > > On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> > >
> > > On Sat, 17 Apr 2021 at 22:57, Ralph Goers  > > > 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-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)

2021-04-18 Thread sebb
On Sun, 18 Apr 2021 at 00:03, Ralph Goers  wrote:
>
>
>
> > On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> >
> > On Sat, 17 Apr 2021 at 22:57, Ralph Goers  > > 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-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)

2021-04-17 Thread Ralph Goers


> On Apr 17, 2021, at 3:32 PM, sebb  wrote:
> 
> On Sat, 17 Apr 2021 at 22:57, Ralph Goers  > 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)

2021-04-17 Thread sebb
On Sat, 17 Apr 2021 at 22:57, Ralph Goers  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  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"?
>
> 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 
> >> .
> >
> > 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 
>  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-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)

2021-04-17 Thread Ralph Goers
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-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)

2021-04-17 Thread Ralph Goers
You should see my other message but I will reply to your questions also.

> On Apr 16, 2021, at 1:37 PM, 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"?

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

2021-04-17 Thread Ralph Goers
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  wrote:
> 
> On Fri, 16 Apr 2021 at 19:39, Ralph Goers  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 
>> .  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.
> 
> 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  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'

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

2021-04-17 Thread sebb
On Fri, 16 Apr 2021 at 19:39, Ralph Goers  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 
> .  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.

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

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

2021-04-16 Thread 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 thing

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

2021-04-16 Thread 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)

2021-04-16 Thread 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)

2021-04-16 Thread 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: Redesign of Commons website generation (was: CMS Deprecated. Removal of configs and move to new publishing area)

2021-04-16 Thread 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)

2021-04-16 Thread 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)

2021-04-16 Thread 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

2021-04-16 Thread 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
> t

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

2021-04-15 Thread Gilles Sadowski
Hello.

[Sorry for jumping into the discussion while missing the meaning of
most of what is being said (and cutting it).]

> [...]
> > 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
?
Could we perhaps take this opportunity to do away with SVN
and "site-content" and have some "mvn" target directly populate
the web site?

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

-
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

2021-04-15 Thread Gavin McDonald



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.

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

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

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. 

> 
> > > 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 
the way Infrastructure is doing things, by all means escalate.

> >
> > > Gavin McDonald (ASF Infra)
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

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



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

2021-04-15 Thread sebb
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.

Further, any developers with local workspaces will need to update
these to the new URL.

What are the arrangements for the staging areas?
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?

> > Any questions, let me know.
>
> Is it *really* necessary for the files to be moved?
>
> > Gavin McDonald (ASF Infra)
> >
> > -
> > 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

2021-04-14 Thread sebb
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

> Any questions, let me know.

Is it *really* necessary for the files to be moved?

> Gavin McDonald (ASF Infra)
>
> -
> 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



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

2021-04-14 Thread Gavin McDonald
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.

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

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.

Any questions, let me know. 

Gavin McDonald (ASF Infra)

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