commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: We will not be able to update our websites...
Date Tue, 18 Dec 2012 21:17:37 GMT

On Dec 18, 2012, at 1:03 PM, Olivier Lamy wrote:

> 2012/12/18 Ralph Goers <ralph.goers@dslextreme.com>:
>> 
>> On Dec 18, 2012, at 12:18 PM, Olivier Lamy wrote:
>> 
>>> 2012/12/18 Ralph Goers <ralph.goers@dslextreme.com>:
>>>> 
>>>> On Dec 18, 2012, at 9:10 AM, Olivier Lamy wrote:
>>>> 
>>>>> 2012/12/18 Ralph Goers <ralph.goers@dslextreme.com>:
>>>>>> I still don't understand why you are committing the subprojects to
svn.  That is not required.  Just use stage-deploy to deploy to a local directory on your
computer, then copy that under where you have the production web site checked out and check
it in.  See http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>> 
>>>>> As I can see in section "Managing Sub-project Sites" this doc says
>>>>> "Make sure all that is added to svn and commit it."
>>>>> So subsites must be checked in (here I configure this to be done tru
a
>>>>> maven plugin and not manually)
>>>>> Infra will be able to use as production web site:
>>>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or
>>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>> but this one still doesn't exist, I will ping infra on the jira entry
>>>>> for their preference).
>>>> 
>>>> Step 6 is referring to checking it in directly to https://svn.apache.org/repos/infra/websites/production/logging/content/
in the subdirectory that is listed in extpaths.txt, not some other subversion location.  If
you look under log4j, for example, you will see a directory for each release and a directory
that is a symlink to the current release (for Log4j 2 the 2.x directory links to log4j-2.0-beta3.
>>>> 
>>>>> 
>>>>> So if you want sub-project sites available AFAIK this (check in all
>>>>> content) must be done (or I misunderstand something: -)).
>>>>> 
>>>>> Makes sense ?
>>>> 
>>>> Not really.
>>> So maybe I misunderstood what you want to do.
>>> 
>>> What I understood:
>>> 1) main site is build from
>>> http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>> (and marked as cms content so possible to modify files via the cms ui)
>>> technically a buildbot job run the maven build and commit the
>>> generated site to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (this svn path
>>> will serve as infra for web site content staging then live) (note I
>>> did the change for infra requirement on sources structure)
>>> 2) due to #1 sub project content (take lang) must be committed to
>>> http://svn.apache.org/repos/asf/commons/cms-site/trunk/lang
>> 
>> This step is not necessary.  sub-project content can be committed directly to https://svn.apache.org/repos/infra/websites/production/commons/content/lang/lang-n.n
or https://svn.apache.org/repos/infra/websites/production/commons/content/proper/lang/lang-n.n
depending on what is in extpaths.txt
>> 
> 
> Ok I see now (as I said in a previous mail) I believed you wanted to
> use  http://svn.apache.org/repos/asf/commons/cms-site/trunk/ rather
> than https://svn.apache.org/repos/infra/websites/production/commons/content

I'm not sure what http://svn.apache.org/repos/asf/commons/cms-site/trunk is.  It doesn't seem
to be the actual CMS site.  That seems to be at http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/.
Personally, I prefer commons/cms-site/trunk as the actually location for the CMS content instead
of proper/commons-site/trunk. But only one of the two is needed and it would be where the
CMS content resides.

As I understand it we don't have a choice, we have to use https://svn.apache.org/repos/infra/websites/production/commons/content
for the production site.

Ralph



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message