Return-Path:
+ Apart from all of the general ApacheCon events, there are a number of + Forrest-specific events. In chronological order ... +
+ ++ Wednesday 11 October - Official ApacheCon session + conducted by Ferdinand Soethe. + Read more. +
- +@@ -325,7 +341,7 @@ Apart from all of the general ApacheCon events, there are a number of Forrest-specific events. In chronological order ...
- +Friday 30 June - Official ApacheCon session @@ -337,7 +353,7 @@
@@ -348,7 +364,7 @@ Apart from all of the general ApacheCon events, there is one Forrest-specific event.
- +Tuesday 13 December at 09:00 to 10:00 - Official ApacheCon session @@ -357,7 +373,7 @@ Schedule Session TU01. The event is only open to ApacheCon attendees.
- +@@ -369,7 +385,7 @@ Apart from all of the general ApacheCon events, there are a number of Forrest-specific events. In chronological order ...
- +Monday 18 July and Tuesday 19 July all day - Open to any Apache @@ -377,7 +393,7 @@ about Apache Forrest and maybe fix some bugs. We will probably collaborate with the Apache Lenya committers too.
- +Monday 18 July commencing at 18:30 - We will go out to dinner and then @@ -390,7 +406,7 @@ The event is open to anybody, you don't need to be attending ApacheCon. Venue and Directions: Gather at the foyer of the ApacheCon.
- +Tuesday 19 July commencing at 18:30 - Johannes Schaefer will @@ -399,7 +415,7 @@ See further information.
- +Wednesday 20 July at 14:30 to 15:30 - Official ApacheCon session @@ -408,7 +424,7 @@ Schedule Session WE16. The event is only open to ApacheCon attendees.
- +Wednesday 20 July commencing at 20:00 - Informal get together to Modified: forrest/site/events.pdf URL: http://svn.apache.org/viewvc/forrest/site/events.pdf?view=diff&rev=453465&r1=453464&r2=453465 ============================================================================== Binary files - no diff available. Modified: forrest/site/forrest-issues.html URL: http://svn.apache.org/viewvc/forrest/site/forrest-issues.html?view=diff&rev=453465&r1=453464&r2=453465 ============================================================================== --- forrest/site/forrest-issues.html (original) +++ forrest/site/forrest-issues.html Thu Oct 5 19:10:48 2006 @@ -189,33 +189,36 @@
-http://issues.apache.org/jira/browse/FOR-868 -
-We need to add some notes to the upgrading_0*.html doc for the upcoming release. This would most easily be done after attending to <a href="http://issues.apache.org/jira/browse/FOR-865" title="Add missing entries to status.xml to generate the changes list">FOR-865</a> "Add missing entries to status.xml to generate the changes list".
-@@ -303,7 +295,7 @@ <br/>
@@ -321,39 +313,31 @@ <br/> <a href="http://marc.theaimsgroup.com/?t=114274836600001">http://marc.theaimsgroup.com/?t=114274836600001</a>
-http://issues.apache.org/jira/browse/FOR-735 +http://issues.apache.org/jira/browse/FOR-868
-(At this point I didn't try this scenario step by step any more; basically it is what we did to setup the site, except that we copied our project data from forrest 0.6 before trying the pdf links) -<br/> - -<br/> -- run forrest webapp to create an empty webapp -<br/> -- configure Tomcat to run the webapp (we did it by creating a context descriptor and put it onder Tomcat's config directory) -<br/> -- the pdf links give an error "Resource Not Found"
+We need to add some notes to the upgrading_0*.html doc for the upcoming release. This would most easily be done after attending to <a href="http://issues.apache.org/jira/browse/FOR-865" title="Add missing entries to status.xml to generate the changes list">FOR-865</a> "Add missing entries to status.xml to generate the changes list".
-http://issues.apache.org/jira/browse/FOR-711 +http://issues.apache.org/jira/browse/FOR-533
-Now that we are using the locationmap extensively it is showing up just how innefficient it is. The problem is that for the majority of requests there are multiple reqeuests to the locationmap. We can make things much faster (especially on the first page request) by caching results in the locationmap. +
The information in the plugins.xml file would be better kept in the plugin directory and added to the plugins.xml file when deployed. This would reduce the amount of duplication in the plugins config files. <br/> <br/> -I think a simple cache will sufice, lets just provide a static hashmap using the hint as a key and, of course, the location as the value. +All the necessary values are now in the plugin build.xml file. <br/> <br/> -If we test all locationmaps and find no result we should record that tere is no result in this hashmap. This will also be a good place to throw an exception so that Cocoon can better report such errors (see <a href="http://issues.apache.org/jira/browse/FOR-701" title="Missing locationmap entry gives poor error">FOR-701</a>)
+This change will require that the plugins.xml file be retrieved from the build directory rather than the plugins directory when building the plugin documentation pages. We will therefore need a fall back to retrieve this file from the network if it is not currently available - this can be done with the locationmap@@ -365,35 +349,51 @@ <br/>
-http://issues.apache.org/jira/browse/FOR-742 +http://issues.apache.org/jira/browse/FOR-735
-The plugin retrieval and deployment process are not quite correct. Recently the projectInfo plugin had its version number incremented and the "unversioned" plugin now relates specifically to 0.8-dev version. That prevents 0.7 from accessing the relevant plugin. +
(At this point I didn't try this scenario step by step any more; basically it is what we did to setup the site, except that we copied our project data from forrest 0.6 before trying the pdf links) <br/> <br/> -The solution is discussed here: +- run forrest webapp to create an empty webapp <br/> -<a href="http://marc.theaimsgroup.com/?t=113176328300002">http://marc.theaimsgroup.com/?t=113176328300002</a>
+- configure Tomcat to run the webapp (we did it by creating a context descriptor and put it onder Tomcat's config directory) +<br/> +- the pdf links give an error "Resource Not Found"-http://issues.apache.org/jira/browse/FOR-533 +http://issues.apache.org/jira/browse/FOR-711
-The information in the plugins.xml file would be better kept in the plugin directory and added to the plugins.xml file when deployed. This would reduce the amount of duplication in the plugins config files. +
Now that we are using the locationmap extensively it is showing up just how innefficient it is. The problem is that for the majority of requests there are multiple reqeuests to the locationmap. We can make things much faster (especially on the first page request) by caching results in the locationmap. <br/> <br/> -All the necessary values are now in the plugin build.xml file. +I think a simple cache will sufice, lets just provide a static hashmap using the hint as a key and, of course, the location as the value. <br/> <br/> -This change will require that the plugins.xml file be retrieved from the build directory rather than the plugins directory when building the plugin documentation pages. We will therefore need a fall back to retrieve this file from the network if it is not currently available - this can be done with the locationmap
+If we test all locationmaps and find no result we should record that tere is no result in this hashmap. This will also be a good place to throw an exception so that Cocoon can better report such errors (see <a href="http://issues.apache.org/jira/browse/FOR-701" title="Missing locationmap entry gives poor error">FOR-701</a>) ++http://issues.apache.org/jira/browse/FOR-742 +
+The plugin retrieval and deployment process are not quite correct. Recently the projectInfo plugin had its version number incremented and the "unversioned" plugin now relates specifically to 0.8-dev version. That prevents 0.7 from accessing the relevant plugin. +<br/> + +<br/> +The solution is discussed here: +<br/> +<a href="http://marc.theaimsgroup.com/?t=113176328300002">http://marc.theaimsgroup.com/?t=113176328300002</a>
+http://issues.apache.org/jira/browse/FOR-200 +
+The locationmap gives us the ability to specify where sources are, both for Forrest and for the users. +<br/> + +<br/> +Beware that it will not work for raw files that are not linked, as this "feature" currently uses a fixed dir being being copied by Ant.
+@@ -473,7 +485,7 @@ <br/> I found out about this because my sitemap uses the fo2pdf too (docbook to PDF), and had to add the serializer.
@@ -489,7 +501,7 @@ <br/> <map:match pattern="old_site/**.html">
@@ -501,7 +513,7 @@ <br/> (Perhaps we need Jira sub-tasks for each plugin.)
@@ -509,7 +521,7 @@
Until recently we could run forrest as a WAR. With today's SVN r356945 it gets past the Cocoon startup phase, then on the first client request it suffers some error which causes a NoSuchMethodError. See attached log ... no other clues. This happens for any site, e.g. 'forrest seed-sample war'. All is okay for 'forrest seed-sample run'.
@@ -539,7 +551,7 @@ <br/> Tidy up the pluginTempate/status.xml
@@ -549,18 +561,6 @@ <br/> <a href="http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/index.xml?r1=365495&r2=365494&pathrev=365495">http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/index.xml?r1=365495&r2=365494&pathrev=365495</a>
-http://issues.apache.org/jira/browse/FOR-200 -
-The locationmap gives us the ability to specify where sources are, both for Forrest and for the users. -<br/> - -<br/> -Beware that it will not work for raw files that are not linked, as this "feature" currently uses a fixed dir being being copied by Ant.
-+http://issues.apache.org/jira/browse/FOR-936 +
+When moving from one page to another and switching locales in between, the chosen locale is lost when entering the new page. To reproduce: +<br/> + +<br/> +1) set up and run forrest with i18n ON +<br/> +2) open a localized page +<br/> +3) switch locale by appending '?locale=XY' in the address field +<br/> +4) open another page available in both the original locale (before the switch) and the new locale XY +<br/> +5) notice how the new page is displayed in the original locale, NOT the expected XY locale +<br/> + +<br/> +Although one could argue that the described behaviour is wanted in some cases, I believe that to most users it would be natural that the locale is "sticky" once changed - it should not change back by itself. Thus, the "sticky" behaviour should be default in Forrest. +<br/> + +<br/> +The fix is simple, patch to come soon.
+@@ -631,7 +659,15 @@ <br/> --tim
+http://issues.apache.org/jira/browse/FOR-635 +
+We used to enable images to be placed in the xdocs/images directory. However, now they are intended to go in the resources/images directory instead. Both methods will work for html pages, but only the latter method for the PDF pages.
+@@ -693,27 +729,7 @@ <br/> </html>
-http://issues.apache.org/jira/browse/FOR-861 -
-The docs for retrieving content from remote locations [1] have not kept up with Tims wonderful naming conventions for the locationmap [2] -<br/> - -<br/> -We need to update the docs to reflect the situation described in [3] (don't miss the correction in the next message) -<br/> - -<br/> -[1] <a href="http://forrest.apache.org/docs_0_80/locationmap.html#source-via-http">http://forrest.apache.org/docs_0_80/locationmap.html#source-via-http</a> -<br/> -[2] <a href="http://forrest.apache.org/docs_0_80/locationmap.html#namingConvention">http://forrest.apache.org/docs_0_80/locationmap.html#namingConvention</a> -<br/> -[3] <a href="http://marc.theaimsgroup.com/?t=114492612100001&r=1&w=2">http://marc.theaimsgroup.com/?t=114492612100001&r=1&w=2</a>
-@@ -721,7 +737,7 @@
The main/webapp/resources/stylesheets/linkmap-to-document.xsl has a workaround for a side-effect to the of the workaround for issue <a href="http://issues.apache.org/jira/browse/FOR-675" title="upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.">FOR-675</a>.
@@ -738,14 +754,6 @@ - ?? <br/>
--http://issues.apache.org/jira/browse/FOR-635 -
-We used to enable images to be placed in the xdocs/images directory. However, now they are intended to go in the resources/images directory instead. Both methods will work for html pages, but only the latter method for the PDF pages.