svn commit: r880797 - in /websites/production/tapestry/content: cache/main.pageCache confluence-site-setup.html

2013-10-01 Thread buildbot
Author: buildbot
Date: Wed Oct  2 02:20:40 2013
New Revision: 880797

Log:
Production update by buildbot for tapestry

Modified:
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/confluence-site-setup.html

Modified: websites/production/tapestry/content/cache/main.pageCache
==
Binary files - no diff available.

Modified: websites/production/tapestry/content/confluence-site-setup.html
==
--- websites/production/tapestry/content/confluence-site-setup.html (original)
+++ websites/production/tapestry/content/confluence-site-setup.html Wed Oct  2 
02:20:40 2013
@@ -69,10 +69,6 @@
 
 Related Articles
  Page:
- Confluence Site Setup
-
-
- Page:
  Developer Information
 
 
@@ -91,62 +87,75 @@
  Page:
  Building Tapestry from Source
 
+
+ Page:
+ Confluence Site Setup
+
 
  
 
-This document describes our site setup: what is where and how does it 
work.
+This document describes our web site setup: what is where and how it 
works.
 
 Overview
 
-Our website and documentation are kept in Confluence. 
+Most of the web site and documentation (with the notable exception of the 
Javadoc API pages) are kept in Confluence.
 
-Since the confluence instance at https://cwiki.apache.org/confluence/";>https://cwiki.apache.org/confluence/
 isn't capable of handling a lot of incoming requests, all spaces are 
statically exported. 
+Since the Confluence instance at https://cwiki.apache.org/confluence/";>https://cwiki.apache.org/confluence/
 isn't capable of handling a lot of incoming requests, all wiki spaces are 
statically exported. The SiteExporter program is responsible for that. Once a 
page in Confluence changes, that page gets re-exported automatically.
 
-The Autoexport plugin for Confluence is responsible for that. Once a page 
in Confluence changes, that page gets re-exported automatically. The Autoexport 
plugin is configured to export the pages to a directory on thor (the machine 
Confluence is running on). From there a cron job copies the exports to 
/www/confluence-exports on people.apache.org. 
+How 
SiteExporter works
 
-On people.apache.org another cron job copies the exported Tapestry 
space to ~uli/public_html/tapestry-site/ which is available as http://people.apache.org/~uli/tapestry-site/";>http://people.apache.org/~uli/tapestry-site/.
 
+For more details see the https://svn.apache.org/repos/asf/tapestry/tapestry-site/trunk/README";>SiteExporter
 README.
 
-https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif"; 
width="16" height="16" alt="" border="0">This 
will shortly be updated to copy our space to a 
/www/tapestry.apache.org which is the folder that itself is copied out 
and available as http://tapestry.apache.org";>http://tapestry.apache.org.
+SiteExporter is a command-line Java program that is run hourly (currently 
at 20 minutes after the hour) from Apache's BuildBot. It makes a web service 
call to Confluence (to its RSS feed, actually) to get a list of each page that 
has changed since the last run, and the HTML-formatted export of those pages. 
For each, it post-processes the file (described below). Finally, SiteExporter 
commits all changed HTML files into Tapestry's part of the Apache Subversion 
repository, which (nearly instantly) makes it available to the public at http://tapestry.apache.org";>http://tapestry.apache.org, and commit 
emails are sent to Tapestry's "commits" mailing list.
 
-Yes, this is a bit http://en.wikipedia.org/wiki/Rube_Goldberg_machine"; >Rube Goldberg, 
and the multiple steps, hops, and cron jobs mean it can be quite some time 
between a change in Confluence, and the content being visible (possibly a 
couple of hours).
+Attachments (to Confluence pages) are exported in roughly the same way.
 
-https://cwiki.apache.org/confluence/images/icons/emoticons/information.gif";
 width="16" height="16" alt="" border="0">Content copied to /www/tapestry.apache.org is not 
immediately visible; yet another cron job (!) copies this content to the main 
Apache web server, about once an hour. On the other hand, content ~uli 
is available in real time.
+The time between saving a change in Confluence and seeing the result on the 
public site is at most 1 hour, depending on when you do it. If you save a 
change at 19 minutes after the hour you'll see the change in about a minute. If 
you publish it at 21 minutes after the hour then you'll have to wa

[CONF] Apache Tapestry > Confluence Site Setup

2013-10-01 Thread Bob Harner (Confluence)







Confluence Site Setup
Page edited by Bob Harner


Comment:
Rewrote to describe the SiteExporter program rather than the dead Autoexport program


 Changes (24)
 




...
{float}   
This document describes our web site setup: what is where and how does it works. 
 h1. Overview  
Our website and documentation are kept in Confluence.  
Most of the web site and documentation (with the notable exception of the Javadoc API pages) are kept in Confluence. 
 
Since the cConfluence instance at https://cwiki.apache.org/confluence/ isn't capable of handling a lot of incoming requests, all wiki spaces are statically exported. The SiteExporter program is responsible for that. Once a page in Confluence changes, that page gets re-exported automatically. 
 
The Autoexport plugin for Confluence is responsible for that. Once a page in Confluence changes, that page gets re-exported automatically. The Autoexport plugin is configured to export the pages to a directory on thor (the machine Confluence is running on). From there a cron job copies the exports to {{/www/confluence-exports}} on people.apache.org.  
h2. How SiteExporter works 
 
On people.apache.org _another_ cron job copies the exported Tapestry space to {{~uli/public_html/tapestry-site/}} which is available as [http://people.apache.org/~uli/tapestry-site/].  
_For more details see the [SiteExporter README|https://svn.apache.org/repos/asf/tapestry/tapestry-site/trunk/README]._ 
 
{note} This will shortly be updated to copy our space to a {{/www/tapestry.apache.org}} which is the folder that itself is copied out and available as [http://tapestry.apache.org]. {note} 
SiteExporter is a command-line Java program that is run hourly (currently at 20 minutes after the hour) from Apache's BuildBot. It makes a web service call to Confluence (to its RSS feed, actually) to get a list of each page that has changed since the last run, and the HTML-formatted export of those pages. For each, it post-processes the file (described below). Finally, SiteExporter commits all changed HTML files into Tapestry's part of the Apache Subversion repository, which (nearly instantly) makes it available to the public at http://tapestry.apache.org, and commit emails are sent to Tapestry's "commits" mailing list. 
 
Yes, this is a bit [Rube Goldberg|http://en.wikipedia.org/wiki/Rube_Goldberg_machine], and the multiple steps, hops, and cron jobs mean it can be quite some time between a change in Confluence, and the content being visible (possibly a couple of hours). 
Attachments (to Confluence pages) are exported in roughly the same way. 
 
{info} Content copied to {{/www/tapestry.apache.org}} is not immediately visible; yet another cron job \(!) copies this content to the main Apache web server, about once an hour. On the other hand, content {{~uli}} is available in real time. {info} 
The time between saving a change in Confluence and seeing the result on the public site is at most 1 hour, depending on when you do it. If you save a change at 19 minutes after the hour you'll see the change in about a minute. If you publish it at 21 minutes after the hour then you'll have to wait almost an hour. 
 
| HTML files in SVN | https://svn.apache.org/repos/infra/websites/production/tapestry | | Cache File | https://svn.apache.org/repos/infra/websites/production/tapestry/content/cache/main.pageCache | | SiteExporter source | https://svn.apache.org/repos/asf/tapestry/tapestry-site/trunk | | Velocity template | https://svn.apache.org/repos/asf/tapestry/tapestry-site/trunk/template/template.vm |  h3. Post-processing HTML Pages  HTML pages exported from Confluence are post-processed in several ways before being committed to SVN. Here are just a few of the things going on:  * Tagsoup is used to clean up the HTML. * The breadcrumb links are updated. * Empty paragraph () tags are removed from the top of the page. * \{code\} macro output (code examples) are detected, and SyntaxHighlighter _javascript_ links are added to the page when needed. * \{include\} tags (when one Confluence page includes another) are detected, causing the _including_ page to be regenerated autoamtically. * \{children\} tags are also detected and handled  h2. Manual Intervention  You can cause the _whole site_ to be republished by deleting the main.pageCache file (above) in the subversion repo. This is usually only needed after changing the template.  h2. Changing SiteExporter itself  Currently the SiteExporter source code is an unmodified copy of a program of the same name written by Dan Kulp for the 

[jira] [Assigned] (TAP5-1767) Making URLRewrite optionally available for smooth upgrading

2013-10-01 Thread Thiago H. de Paula Figueiredo (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thiago H. de Paula Figueiredo reassigned TAP5-1767:
---

Assignee: Thiago H. de Paula Figueiredo

> Making URLRewrite optionally available for smooth upgrading
> ---
>
> Key: TAP5-1767
> URL: https://issues.apache.org/jira/browse/TAP5-1767
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Angelo Chen
>Assignee: Thiago H. de Paula Figueiredo
>  Labels: URLrewrie
>
> 1. removal of URLRewrite in 5.3 make it difficult to upgrade to 5.3 as we 
> have to test all the rules again.
> 2. lack of outbound link rewriting in LinkTransformer has totally stopped my 
> effort in upgrading to 5.3
> I'd suggest to make the urlrewrite a separate module so we can upgrade to 5.3 
> smoothly. thanks



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (TAP5-1767) Making URLRewrite optionally available for smooth upgrading

2013-10-01 Thread Thiago H. de Paula Figueiredo (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thiago H. de Paula Figueiredo closed TAP5-1767.
---

   Resolution: Fixed
Fix Version/s: 5.3
   5.2
   5.4

The URL rewriter API code from 5.1.0.5 was copied and adapted for use with 
Tapestry 5.2+ in a separate package. Sources at 
https://github.com/thiagohp/tapestry-url-rewriter/, JAR at the Maven Central 
Repository: 

br.com.arsmachina
tapestry-url-rewriter
1.0.1


Notice version 2.0.0 of tapestry-url-rewriter is not backward-compatible with 
1.0.1, as 2.0.0 removes all the outgoing URL support, as LinkTransformer is 
better at it.

> Making URLRewrite optionally available for smooth upgrading
> ---
>
> Key: TAP5-1767
> URL: https://issues.apache.org/jira/browse/TAP5-1767
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Angelo Chen
>Assignee: Thiago H. de Paula Figueiredo
>  Labels: URLrewrie
> Fix For: 5.4, 5.2, 5.3
>
>
> 1. removal of URLRewrite in 5.3 make it difficult to upgrade to 5.3 as we 
> have to test all the rules again.
> 2. lack of outbound link rewriting in LinkTransformer has totally stopped my 
> effort in upgrading to 5.3
> I'd suggest to make the urlrewrite a separate module so we can upgrade to 5.3 
> smoothly. thanks



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (TAP5-2191) PropertyOutputContext getAnnotation - extends AnnotationProvider

2013-10-01 Thread Ryszard Trojnacki (JIRA)
Ryszard Trojnacki created TAP5-2191:
---

 Summary: PropertyOutputContext getAnnotation - extends 
AnnotationProvider
 Key: TAP5-2191
 URL: https://issues.apache.org/jira/browse/TAP5-2191
 Project: Tapestry 5
  Issue Type: Improvement
  Components: tapestry-core
Reporter: Ryszard Trojnacki
Priority: Trivial


For editing (PropertyEditior) there is PropertyEditContext which has method 
getAnnotation (its from interface AnnotationProvider). This method is very 
usefull to add parameters to editor.

For displaying (PropertyDisplay) there is PropertyOutputContext which 
unfortunately doesn't has this method (is not extending interface 
AnnotationProvider).

My proposition is to add interface AnnotationProvider to PropertyOutputContext.

This change will only require to modify file PropertyOutputContext by adding 
interface AnnotationProvider and AbstractPropertyOutput by implementing method 
getAnnotation:
public  T getAnnotation(Class annotationClass)
{
return model.getAnnotation(annotationClass);
}




--
This message was sent by Atlassian JIRA
(v6.1#6144)