Return-Path:
+ Each plugin has a build.xml file which defines its version information. + Please keep that synchronised with the plugins.xml files. + Later + FOR-533 + will generate this from the various build.xml files.
The Apache Forrest committers manage these files in SVN and publish @@ -738,7 +744,7 @@
Plugins can use the Forrest locationmap to expose resources to your project and other plgins. To use this functionality add your locationmap.xml file to the root of the plugin directory.
We have an issue for the status of locationmap development.
- +Dispatcher (previous codename Forrest Views) is the collective name for the various pieces of functionality that are intended to replace skins in the future. They allow for a much more @@ -809,35 +815,35 @@ your plugin.
Once Dispatcher becomes stable we will add this match to the default locationmap which is generated when you seed a new plugin, but for now it must be done manually.
- +Plugins can define properties that each project can over-ride. For more information see the issue below.
We have an issue for the status of this new configuration system.
- +This section will provide some example plugins to help illustrate the steps discussed above.
- +-http://issues.apache.org/jira/browse/FOR-707 +http://issues.apache.org/jira/browse/FOR-533
-There is next to no documentation about i18n, just a pretty poor FAQ entry that points at an issue that has now been closed. -<br> - -<br> -Cheche wrote a blog entry on his work: +
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> -<a href="http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/">http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/</a> +All the necessary values are now in the plugin build.xml file. <br> <br> -We could, at the very least use the locationmap to pull this content into our site [OT: I wonder if this could be a way to generate more documentation?)
+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-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-711 +http://issues.apache.org/jira/browse/FOR-707
-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. +
There is next to no documentation about i18n, just a pretty poor FAQ entry that points at an issue that has now been closed. <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. +Cheche wrote a blog entry on his work: <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 FOR-701)
+<a href="http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/">http://casa.che-che.com/blog/2005/05/10/internalization-a-site-using-forrest-07-dev/</a> +<br> + +<br> +We could, at the very least use the locationmap to pull this content into our site [OT: I wonder if this could be a way to generate more documentation?)-http://issues.apache.org/jira/browse/FOR-735 +http://issues.apache.org/jira/browse/FOR-711
-(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) +
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> -- run forrest webapp to create an empty webapp +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> -- 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"
+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 FOR-701)-http://issues.apache.org/jira/browse/FOR-533 +http://issues.apache.org/jira/browse/FOR-742
-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. +
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> -All the necessary values are now in the plugin build.xml file. -<br> - +The solution is discussed here: <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
+<a href="http://marc.theaimsgroup.com/?t=113176328300002">http://marc.theaimsgroup.com/?t=113176328300002</a>-http://issues.apache.org/jira/browse/FOR-209 -
-When there are two levels of tabs, the selected first level tab does not get highlighted, nor are there any other visual or structural clues as to which first-level tab is active, and which contains the displayed 2nd level tabs. -<br> - -<br> -This is checked with both the default skin, and with tigris-style. -<br> +http://issues.apache.org/jira/browse/FOR-211
+In the the generated site.html all of the external links are broken (i.e. the href attributes are like ... error:#ext:forrest).
-http://issues.apache.org/jira/browse/FOR-211 +http://issues.apache.org/jira/browse/FOR-209 +
+When there are two levels of tabs, the selected first level tab does not get highlighted, nor are there any other visual or structural clues as to which first-level tab is active, and which contains the displayed 2nd level tabs. +<br> + +<br> +This is checked with both the default skin, and with tigris-style. +<br>
-In the the generated site.html all of the external links are broken (i.e. the href attributes are like ... error:#ext:forrest).
+http://issues.apache.org/jira/browse/FOR-645 +
+Use this issue to provide patches for the whitespace cleanup.
+@@ -636,14 +644,6 @@ <br> This Issue will be used to announce which section of the repository is due to be cleaned next. Please keep discussion on that mail thread.
--http://issues.apache.org/jira/browse/FOR-645 -
-Use this issue to provide patches for the whitespace cleanup.