Staging area for website changes

[Marshall Schor <ms...@schor.com>]

Most website systems have a CMS (Content Management System) to allow
staging of changes, review, and making the changes go live, with some
automation.

Apache is considering such a system (from Day software) but it isn't yet
available. 

I'd like to have something where we could do some testing and evaluation
of new stuff before it goes live.  I'm thinking of using a convention of
uima.apache.org/staging root to do this.  The site:deploy goal would put
things here, and after review, we would move things to the official spots. 

We could put an "index.html" under this that says this is a staging
area, should not be "linked" to, and that information here is not
officially approved and is subject to frequent change.

Another alternative: Maven uses a somewhat different convention: they
have for each plugin, for instance, a staging area that is named
maven.apache.org/plugins/abc-plugin-1.2.1  - that is, they append the
version number to the subproject's top level name. 

Do either of these seem like a reasonable approach for now, until
something better comes along?  My leaning at this point is to the
simpler first alternative, above.

-Marshall

Re: Staging area for website changes

[Marshall Schor <ms...@schor.com>]

I just found out that the "default" location for the goal "stage-deploy"
of maven's site plugin is exactly this convention. Here's what the
website for site says:

The staged site will be deployed to this URL. If you don't specify this,
the default-value will be
"${project.distributionManagement.site.url}/staging", where "project" is
either the current project or, in a reactor build, the top level project
in the reactor.

I'll update the parent-pom-top to add the distributionManagement info
for the site to reflect the site plugin requirements (e.g., it must use
the "scp:" protocol).

Note that your maven settings file needs to add 2 entries to support the
server authentication; one for the normal site deploy, and the other for
the staging deploy.

For example (not yet tested/verified):

    <!-- To publish a website of some part of UIMA -->
    <server>
      <id>uima.apache.org</id>
      <username>schor</username>
      <password>  -- insert encrypted password here -- </password>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>
    <!-- To stage a website of some part of Maven -->
    <server>
      <id>stagingSite</id> <!-- must match hard-coded repository
identifier in site:stage-deploy -->
      <username>schor</username>
      <password>  -- insert encrypted password here -- </password>
      <filePermissions>664</filePermissions>
      <directoryPermissions>775</directoryPermissions>
    </server>
 
-Marshall

On 6/3/2010 3:22 AM, Tommaso Teofili wrote:
> 2010/6/2 Marshall Schor <ms...@schor.com>
>
>   
>> Most website systems have a CMS (Content Management System) to allow
>> staging of changes, review, and making the changes go live, with some
>> automation.
>>
>> Apache is considering such a system (from Day software) but it isn't yet
>> available.
>>
>> I'd like to have something where we could do some testing and evaluation
>> of new stuff before it goes live.  I'm thinking of using a convention of
>> uima.apache.org/staging root to do this.  The site:deploy goal would put
>> things here, and after review, we would move things to the official spots.
>>
>> We could put an "index.html" under this that says this is a staging
>> area, should not be "linked" to, and that information here is not
>> officially approved and is subject to frequent change.
>>
>> Another alternative: Maven uses a somewhat different convention: they
>> have for each plugin, for instance, a staging area that is named
>> maven.apache.org/plugins/abc-plugin-1.2.1  - that is, they append the
>> version number to the subproject's top level name.
>>
>> Do either of these seem like a reasonable approach for now, until
>> something better comes along?  My leaning at this point is to the
>> simpler first alternative, above.
>>
>> -Marshall
>>
>>     
> Yes, I would go for the first one too.
> Tommaso
>
>   

Re: Staging area for website changes

[Tommaso Teofili <to...@gmail.com>]

2010/6/2 Marshall Schor <ms...@schor.com>

> Most website systems have a CMS (Content Management System) to allow
> staging of changes, review, and making the changes go live, with some
> automation.
>
> Apache is considering such a system (from Day software) but it isn't yet
> available.
>
> I'd like to have something where we could do some testing and evaluation
> of new stuff before it goes live.  I'm thinking of using a convention of
> uima.apache.org/staging root to do this.  The site:deploy goal would put
> things here, and after review, we would move things to the official spots.
>
> We could put an "index.html" under this that says this is a staging
> area, should not be "linked" to, and that information here is not
> officially approved and is subject to frequent change.
>
> Another alternative: Maven uses a somewhat different convention: they
> have for each plugin, for instance, a staging area that is named
> maven.apache.org/plugins/abc-plugin-1.2.1  - that is, they append the
> version number to the subproject's top level name.
>
> Do either of these seem like a reasonable approach for now, until
> something better comes along?  My leaning at this point is to the
> simpler first alternative, above.
>
> -Marshall
>

Yes, I would go for the first one too.
Tommaso