Return-Path: Delivered-To: apmail-forrest-svn-archive@www.apache.org Received: (qmail 49466 invoked from network); 19 Dec 2005 01:34:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Dec 2005 01:34:18 -0000 Received: (qmail 92127 invoked by uid 500); 19 Dec 2005 01:34:15 -0000 Delivered-To: apmail-forrest-svn-archive@forrest.apache.org Received: (qmail 91888 invoked by uid 500); 19 Dec 2005 01:34:13 -0000 Mailing-List: contact svn-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Forrest Developers List" List-Id: Delivered-To: mailing list svn@forrest.apache.org Received: (qmail 91625 invoked by uid 99); 19 Dec 2005 01:34:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Dec 2005 17:34:09 -0800 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 18 Dec 2005 17:33:57 -0800 Received: (qmail 48789 invoked by uid 65534); 19 Dec 2005 01:33:36 -0000 Message-ID: <20051219013336.48788.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r357603 [7/11] - in /forrest/site: ./ docs_0_60/ docs_0_60/howto/ docs_0_60/howto/bugzilla-patch/ docs_0_70/ docs_0_70/howto/ docs_0_70/howto/cvs-ssh/ docs_0_80/ docs_0_80/howto/ docs_0_80/howto/cvs-ssh/ dtdx/ pluginDocs/plugins_0_70/ plugi... Date: Mon, 19 Dec 2005 01:33:15 -0000 To: svn@forrest.apache.org From: crossley@apache.org X-Mailer: svnmailer-1.0.5 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Modified: forrest/site/docs_0_80/faq.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/faq.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/faq.html (original) +++ forrest/site/docs_0_80/faq.html Sun Dec 18 17:31:25 2005 @@ -625,14 +625,14 @@

There are two ways to control this. If you get an OutOfMemoryError when Cocoon is generating pages, see the first paragraph. If you get an OutOfMemoryError when outside of Cocoon (e.g., copying raw files), see the second paragraph.

The maxmemory property in the forrest.properties file controls +

The maxmemory property in the forrest.properties file controls how much memory Cocoon uses. Like many other properties you can copy them from the default - configuration at main/fresh-site/forrest.properties + configuration at main/fresh-site/forrest.properties

Set the ANT_OPTS environment variable before you run forrest. The exact +

Set the ANT_OPTS environment variable before you run forrest. The exact value you set it to is dependant on your JVM, but something like - ANT_OPTS=-Xmx500M will probably work.

+ ANT_OPTS=-Xmx500M will probably work.

1.8. How can I start forrest in debug mode?

@@ -640,9 +640,9 @@ ^

The forrest.jvmargs property in the forrest.properties file +

The forrest.jvmargs property in the forrest.properties file can be used to start forrest in debug mode on a specific port. - forrest.jvmargs=-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n + forrest.jvmargs=-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

@@ -673,7 +673,7 @@

- The site.xml configuration file is used for two different purposes: + The site.xml configuration file is used for two different purposes: defining the navigation menus, and as a method for defining references to be used when linking between documents. This file is fully explained in @@ -716,7 +716,7 @@

There are examples in the 'forrest seed site' and also the Forrest website documents - are included with the distribution (cd forrest/site-author; + are included with the distribution (cd forrest/site-author; forrest run).

@@ -754,8 +754,8 @@ page break on. All the common block grouping elements support this class, for example, note, warning, p and so on.

If you want these classes to be processed in your HTML documents as well you should add - the following to the extra-css element in your projects - skinconf.xml + the following to the extra-css element in your projects + skinconf.xml

 
@@ -775,7 +775,7 @@
 ^

You would override +

You would override $FORREST_HOME/main/webapp/skins/common/xslt/html/document2html.xsl and edit the "headers/authors" template.

@@ -809,11 +809,11 @@

Unpack the Jimi distribution and copy JimiProClasses.zip to - $FORREST/lib/optional/jimi-1.0.jar.

+ $FORREST/lib/optional/jimi-1.0.jar.

Alternatively you can use JAI (Java Advanced Imaging API at - http://java.sun.com/products/java-media/jai). For more info, see FOP Graphics Packages + http://java.sun.com/products/java-media/jai). For more info, see FOP Graphics Packages

@@ -828,9 +828,9 @@ ^

In tabs.xml, use @href instead of @dir, and omit the trailing '/'. Which +

In tabs.xml, use @href instead of @dir, and omit the trailing '/'. Which file to serve is then a concern of the sitemap. For example, if the "User Manual" tab - should link to manual/Introduction.html then tabs.xml should + should link to manual/Introduction.html then tabs.xml should contain:

   <tab label="User Manual" href="manual"/>

@@ -918,7 +918,7 @@

Use the numeric values for character entities. For example, rather than using - ö use ö + ö use ö

See the XHTML Character Entities and see more discussion at Issue FOR-244.

@@ -946,7 +946,7 @@

but the file content is actually using ISO-8859-1 then you will receive validation errors, especially if you include some non-ASCII characters.

This situation is commonly encountered when you edit the templates created by - forrest seed with your favorite (probably localized) editor without paying + forrest seed with your favorite (probably localized) editor without paying attention to the encoding, or when you create a new file and simply copy the headers from another file.

Although UTF-8 is an encoding well-suited for most languages, it is not usually the @@ -954,16 +954,16 @@ handle different encodings to write the file in disk. With some editors the encoding of the file is preserved, while with others the default is used regardless of the original encoding. In most cases the encoding used to write files can be controlled by setting the - environment variable LANG to an appropriate value, for instance:

+ environment variable LANG to an appropriate value, for instance:

[localhost]$ export LANG=en_US.UTF-8

Of course the appropriate way to set the encoding depends on the editor/OS, but ultimately relys on the user preferences. So you can use the encoding you prefer, as long - as the encoding attribute of the XML declaration matches the actual encoding + as the encoding attribute of the XML declaration matches the actual encoding of the file. This means that if you are not willing to abandon ISO-8859-1 you can always use the following declaration instead:

<?xml version="1.0" encoding="ISO-8859-1"?>

Another option is to use "character entities" such as ö - (ö) or the numeric form ö (ö).

Another option is to use "character entities" such as ö + (ö) or the numeric form ö (ö).

Another related issue is that your webserver needs to send http headers with the matching charset definitions to the html page.

Here are some references which explain further: GT2004 presentation by Torsten @@ -980,7 +980,7 @@

A set of symbols is available. See the demonstration in a fresh 'forrest seed' site (at samples/xml-entities.html). - For example, use "&myp-t;" to represent the + For example, use "&myp-t;" to represent the project name together with trademark symbol "My Project Name™". Avoid lengthy typing and potential spelling errors. @@ -1027,7 +1027,7 @@

To serve, for example a legacy HTML site, add something like the following to your project's sitemap and place the source content at the - src/documentation/content/xdocs/old_site/ directory.

+ src/documentation/content/xdocs/old_site/ directory.

 <map:match pattern="old_site/**.html">
  <map:select type="exists">
@@ -1093,8 +1093,8 @@
 ^

You can configure the proxy in the forrest.properties file. Set the - proxy.host and proxy.port accordingly (the port will default +

You can configure the proxy in the forrest.properties file. Set the + proxy.host and proxy.port accordingly (the port will default to port 80).

@@ -1103,7 +1103,7 @@ ^

If you have:<version>$Revision: 1.30 +

If you have:<version>$Revision: 1.30 $</version>The '1.30' will be extracted and displayed at the bottom of the page as "version 1.30". See for example the bottom of the Using Forrest document.

@@ -1119,13 +1119,13 @@

Forrest uses a configuration file to control the processing done by the Apache Cocoon command-line called cli.xconf

Your project can supply its own cli.xconf and define patterns for URIs to +

Your project can supply its own cli.xconf and define patterns for URIs to exclude. There are also other powerful configuration features.

This means creating a directory src/documentation/conf (or wherever - ${forrest.conf-dir} points) and copying - $FORREST_HOME/main/webapp/WEB-INF/cli.xconf to it. Declare the location of +

This means creating a directory src/documentation/conf (or wherever + ${forrest.conf-dir} points) and copying + $FORREST_HOME/main/webapp/WEB-INF/cli.xconf to it. Declare the location of this file in the forrest.properties configuration, e.g. - project.configfile=${project.home}/src/documentation/conf/cli.xconf + project.configfile=${project.home}/src/documentation/conf/cli.xconf

Then edit cli.xconf, and add any exclude sections that you require. The default @@ -1144,7 +1144,7 @@

Note

Wildcards may be used. These are a powerful feature of Cocoon's sitemap. For example, foo/* would match - foo/bar, but not foo/bar/baz — use + foo/bar, but not foo/bar/baz — use foo/** to match that.

@@ -1156,7 +1156,7 @@

This can be done by overriding the - cli.xconf + cli.xconf Cocoon config file, and defining patterns for URLs to exclude.

@@ -1166,7 +1166,7 @@

Certain patterns are claimed by the default sitemaps for special processing. These - include: site, changes, todo, faq, images, my-images, skinconf, community, + include: site, changes, todo, faq, images, my-images, skinconf, community, howto

@@ -1216,8 +1216,8 @@

If you are using JDK 1.4.0 or newer, you can enable headless operation by - running Forrest with the forrest.jvmarg parameter set to - -Djava.awt.headless=true, like this:

+ running Forrest with the forrest.jvmarg parameter set to + -Djava.awt.headless=true, like this:

forrest -Dforrest.jvmargs=-Djava.awt.headless=true site

3.13. How do I make forrest run listen on a different port?

@@ -1338,11 +1338,11 @@

-forrest run -Dforrest.jvmargs="-Djetty.port=80" +forrest run -Dforrest.jvmargs="-Djetty.port=80"

Or copy Forrest's main/webapp/jettyconf.xml file to your project's src/documentation - directory and set the port number in that file. Then do forrest run + directory and set the port number in that file. Then do forrest run

@@ -1354,8 +1354,8 @@

If you use an IDE like Eclipse and want to debug java code in Forrest you need to start Forrest with debugging mode turned on. To do this you need - to add -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,susp end=n - to the forrest.jvmargs property in the forrest.properties + to add -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,susp end=n + to the forrest.jvmargs property in the forrest.properties file. Don't forget to ensure the property is uncommented in that file.

@@ -1367,7 +1367,7 @@

@@ -1384,12 +1384,12 @@ ^

One site.xml file in your project root can replace all the book.xml files (one per - directory) in your site. Internally, Forrest uses site.xml to dynamically generate book.xml +

One site.xml file in your project root can replace all the book.xml files (one per + directory) in your site. Internally, Forrest uses site.xml to dynamically generate book.xml files. However, Forrest first checks for the existence of a book.xml file, so backwards-compatibility is preserved. If a directory has a book.xml file, the book.xml will be used to generate the menu. This supplement is useful in situations where - site.xml-generated menus aren't appropriate. See Menus and + site.xml-generated menus aren't appropriate. See Menus and Linking.

@@ -1398,7 +1398,7 @@ ^

There are two ways. Forrest has a simplifiedDocbook plugin which can +

There are two ways. Forrest has a simplifiedDocbook plugin which can transform the DocBook format into the Forrest "xdocs" format on-the-fly and then render that as normal Forrest documents. Be aware that the stylesheet that does this transformation is deliberately very limited and does not attempt to deal with all DocBook @@ -1429,7 +1429,7 @@ in the components section of the sitemap. See the Cocoon docs for the elements you need to add to define this component. You can see examples - of other components being added in the FORREST_HOME/main/webapp/sitemap.xmap file.

+ of other components being added in the FORREST_HOME/main/webapp/sitemap.xmap file.

You can also use a mixture of the two methods, some handled automatically by Forrest and some directly using DocBook stylesheets. You can also have a mixture of source files as "document-v*" DTD and DocBook.

@@ -1445,10 +1445,10 @@ ^

Do 'forrest -projecthelp' or './build.sh' to find the version +

Do 'forrest -projecthelp' or './build.sh' to find the version number.

To list the properties, add "forrest.echo=true" to your forrest.properties file and - watch the build messages. Doing 'forrest -v' will provide verbose build + watch the build messages. Doing 'forrest -v' will provide verbose build messages.

@@ -1457,17 +1457,17 @@ ^

The logfiles are at build/webapp/WEB-INF/logs/ +

The logfiles are at build/webapp/WEB-INF/logs/

The log level can be raised with the logkit.xconf configuration. If you are +

The log level can be raised with the logkit.xconf configuration. If you are using Forrest in the interactive webapp mode (which is generally easiest for debugging - errors) then see the main/webapp/WEB-INF/logkit.xconf file. If you are + errors) then see the main/webapp/WEB-INF/logkit.xconf file. If you are generating a static site (with command-line 'forrest') then copy - $FORREST_HOME/main/webapp/WEB-INF/logkit.xconf to your project at - src/documentation/conf/logkit.xconf and modify it. See more + $FORREST_HOME/main/webapp/WEB-INF/logkit.xconf to your project at + src/documentation/conf/logkit.xconf and modify it. See more information and efficiency tips with Cocoon logging.

Doing 'forrest -v' will provide verbose build messages to the standard +

Doing 'forrest -v' will provide verbose build messages to the standard output.

Modified: forrest/site/docs_0_80/forrest-contract.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/forrest-contract.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/forrest-contract.html (original) +++ forrest/site/docs_0_80/forrest-contract.html Sun Dec 18 17:31:25 2005 @@ -360,10 +360,10 @@

Note

- Some terminology will assist: {docroot} is the location + Some terminology will assist: {docroot} is the location inside TheProject's file hierarchy where all documentation related - resources are stored. Usually {docroot} equals to - {projecthome}/src/documentation + resources are stored. Usually {docroot} equals to + {projecthome}/src/documentation

@@ -396,17 +396,17 @@

Provide content and configuration ...

Provide XML content in {docroot}/content/xdocs +
Provide XML content in {docroot}/content/xdocs according to the Forrest DTDs or one of the other input formats.
Provide navigation metadata using the configuration files - site.xml and tabs.xml + site.xml and tabs.xml
Provide the skin configuation file in - {docroot}/skinconf.xml + {docroot}/skinconf.xml

Provide its own skin in - {docroot}/skins/{your-skin-name} (Check the current + {docroot}/skins/{your-skin-name} (Check the current Forrest skins and the related pipelines to see what they are doing. Bear in mind that the provided skins are able to be configured and may already meet your needs.)
Provide own DTDs to handle other specialised document types in - {docroot}/resources/schema/dtd + {docroot}/resources/schema/dtd
- and declare those extra DTDs in - {docroot}/resources/schema/catalog.xcat + {docroot}/resources/schema/catalog.xcat
@@ -443,7 +443,7 @@
Provide its own overwriting versions of sitemaps - ({docroot}/sitemap.xmap and other *.xmap files) + ({docroot}/sitemap.xmap and other *.xmap files) ... (be sure you know what you are doing since you are then leaving the area where other Forresters can help you out.

Note

This step is necessary only for Windows users. Linux users can happily skip this section and pass to Setting up SSH access section

If you are a domain user then you should be added to Cygwin users list (See [cygwin-dir]/etc/passwd). +

If you are a domain user then you should be added to Cygwin users list (See [cygwin-dir]/etc/passwd).

Warning

Having an empty passphrase isn't recommended for security reasons. See ssh-agent documentation on how to configure automatic passphrase retaining.

Setting up passphrase access

Note

If this command doesn't work then it can mean that you have an old version of SSH. In this case try ssh -l userxxx cvs.apache.org. Run ssh --help to get all available options.

If now you are logged in to the to the CVS machine without entering the password then everything's Ok. @@ -351,10 +351,10 @@

Add ssh.exe directory to your system PATH environment variable. Say:
-C:\>set PATH=%PATH%;C:\cygwin\bin +C:\>set PATH=%PATH%;C:\cygwin\bin
Add CVS_RSH=ssh environment variable
Add CVS_RSH=ssh environment variable

@@ -369,7 +369,7 @@

In the dialog that comes up:
- Set the CVSROOT to userxxx@cvs.apache.org:/home/cvs + Set the CVSROOT to userxxx@cvs.apache.org:/home/cvs
Set the Authentication to SSH Server

Add the mirrors.cgi as a raw file

As explained in the mirrors document, there will be a two-line CGI wrapper script at the top-level of your website called - mirrors.cgi + mirrors.cgi

Utilising the Forrest concept of raw un-processed content, - add the file as src/documentation/mirrors.cgi + add the file as src/documentation/mirrors.cgi (copy the Forrest project's mirrors.cgi)

- Add the file as src/documentation/xdocs/mirrors.html + Add the file as src/documentation/xdocs/mirrors.html (Use the Forrest project's mirrors.html as a template and edit it to suit.) @@ -465,8 +465,8 @@ (CLI) to the rescue. Add an entry to your project's cli.xconf by copying the default one from - $FORREST_HOME/main/webapp/WEB-INF/cli.xconf to your - src/documentation/conf/ directory (or wherever + $FORREST_HOME/main/webapp/WEB-INF/cli.xconf to your + src/documentation/conf/ directory (or wherever ${forrest.conf-dir} points). Add the following entry ...

@@ -477,7 +477,7 @@
 Run 'forrest' to build your site
 
         That is all that you need to do, Forrest will take care of it from
-        there. Run the 'forrest' command. The mirrors.html page
+        there. Run the 'forrest' command. The mirrors.html page
         will be generated with the skin applied.
       
 

Modified: forrest/site/docs_0_80/howto/howto-buildPlugin.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-buildPlugin.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_80/howto/howto-buildPlugin.html (original)
+++ forrest/site/docs_0_80/howto/howto-buildPlugin.html Sun Dec 18 17:31:25 2005
@@ -502,7 +502,7 @@
         to automate some steps in the process. Since ant
         is distributed as part of Forrest, all you need to do
         is add the ant executable directory to your system path. The
-        name of this directory is tools/ant/bin
+        name of this directory is tools/ant/bin
         in your Forrest program directory.
         (Alternatively you can prefix all calls to ant in
         the following instructions with the full path of the ant binary directory.)
@@ -521,7 +521,7 @@
       structure is almost identical, as are most of the required
       configuration files. In this How-To we will assume that you are creating a 
       plugin in the Forrest source tree. All plugins are developed in the
-      forrest/plugins directory.
+      forrest/plugins directory.
 Run the following set of commands:
        cd [path_to_forrest]/plugins
@@ -541,7 +541,7 @@
 
 Note
 If you plan on building your plugin elsewhere you can copy the
-      build.xml build file to your own plugin work directory and 
+      build.xml build file to your own plugin work directory and 
       use it there.
 
 See 
@@ -558,7 +558,7 @@
 
status.xml
 This file is used to track changes to the plugin
           project and to manage lists of things that still need to be done.
-          At this stage you should correct the person entry
+          At this stage you should correct the person entry
           near the top of the file. It is also a good idea to add a few key
           milestones in the task list towards the bottom of the file.
 As you work on the plugin you should record all major changes in
@@ -580,14 +580,7 @@
 
It is also a good idea to start writing the documentation at this
           stage. The above process created a very simple plugin documentation
           site for you. All you have to do is add the content.
-
-Component Configuration
-If your plugin needs to provide additional Cocoon configuration
-          in the form of an xconf, or if some of the components
-          you are using need a configuration file (such as a JTidy config)
-          you should place them in a conf directory in the root
-          of your plugin.
-
+
 Style notes for plugins hosted at forrest.apache.org
 
             After seeding a new plugin, copy the configuration from an
@@ -595,20 +588,20 @@
             Copy src/documentation/skinconf.xml and 
             src/documentation/content/xdocs/images/project-logo.gif
           
-
+
 Edit the Plugin sitemap file(s)
-The plugin xmap file is a Cocoon sitemap that is mounted
+
The plugin xmap file is a Cocoon sitemap that is mounted
       at a strategic place in the Forrest pipeline. It is in this file
       that you will instruct Forrest how to operate. An input plugin
-      must provide a input.xmap file, an output plugin
-      must provide a output.xmap file, whilst an internal
-      plugin provides a internal.xmap file. In addition, an
-      input plugin may provide a resources.xmap file to
+      must provide a input.xmap file, an output plugin
+      must provide a output.xmap file, whilst an internal
+      plugin provides a internal.xmap file. In addition, an
+      input plugin may provide a resources.xmap file to
       allow the plugin to handle items such as JavaScript files.
 
 Note
 All input plugins should allow the original source to be retrieved
-      by requesting the document with a *.source.xml extension. So
+      by requesting the document with a *.source.xml extension. So
       you should ensure that you provide such a match.
 
 It is beyond the scope of this How-To to give details about how to 
@@ -620,68 +613,68 @@
       all development work on Forrest, you will find
       the developer mailing list
       a very good resource (check the archives before posting, please).
-
+
 Components, Actions and Resources
 If your plugin uses any components (i.e. generators, transformers or
         serializers), actions or resources they must
         be defined in either the xmap for this plugin or one of its parents. The parents
-        of an input.xmap are sitemap.xmap and
-        forrest.xmap, whilst the parent of both 
-        output.xmap and internal.xmap are 
-        sitemap.xmap
+        of an input.xmap are sitemap.xmap and
+        forrest.xmap, whilst the parent of both 
+        output.xmap and internal.xmap are 
+        sitemap.xmap
 
 If you want to use the realpath where the sitemap.xmap of your plugin 
         resides then you need to use 
-        {forrest:plugins}/PLUGIN_NAME instead of {realpath:/}.
+        {forrest:plugins}/PLUGIN_NAME instead of {realpath:/}.
         
 See the examples below for more details.
-
+
 Create the Necessary Resource Files
 
 Fixme (rdg)
 Discuss the XSL files and other such resources
 
-
+
 Create Samples in the Documentation
 Plugin documentation should provide (as a minimum) an
       index page that provides an overview and a set of samples that demonstrate
       the functionality of the plugin. Typically these samples will be
-      provided in a samples subdirectory in the plugin 
-      documentation and will be referenced from both site.xml
-      and tabs.xml configuration files.
+      provided in a samples subdirectory in the plugin 
+      documentation and will be referenced from both site.xml
+      and tabs.xml configuration files.
 Try to provide a sample for all the major functions of your plugin
       and document any configuration that is available.
-
+
 Testing a Plugin
 Since your documentation for the plugin illustrates all of its 
       functionality, you can use that site for testing the plugin. However, you
       must first deploy in your local install of Forrest. Each plugin contains
-      a buildfile that includes a test target. This target, by
+      a buildfile that includes a test target. This target, by
       default, builds the documentation for your plugin.
-Run the command ant test in
+
Run the command ant test in
       the plugins directory.
 Of course, the build should complete without errors.
 
 Note
-You can also use forrest run to interactively examine
+You can also use forrest run to interactively examine
       your documentation (point your browser at 
       http://localhost:8888).
 
 It is also a really good idea to build proper tests for your 
       plugins using a suitable testing framework, for example, 
       WebTest. We recommend that you
-      extend the test target in your plugins build file because
+      extend the test target in your plugins build file because
       this target is also used when performing integration tests on Forrest.
       In addition, we recommend that you use the samples in your documentation 
       for your tests, this way you are documenting your plugin at the same time 
       as writing your tests.
 Ensure that your sitemaps are robust and handle matches for files
       in sub-directories, as well as those at the root level.
-
+
 Testing During Development
 In the current plugin system plugins are not used from their
         src directories, they must first be deployed locally. To do this
-        run the command ant local-deploy.
+        run the command ant local-deploy.
 
 Note
 The test target will do this deployment automatically for you.
@@ -690,47 +683,47 @@
 
 In most cases you can locally deploy a plugin without having to 
         restart Forrest. However, if your plugin changes any configuration
-        files in the conf directory you will, most likely, have 
+        files in the conf directory you will, most likely, have 
         to restart Forrest to see these changes.
-
+
 Releasing a Plugin
-
+
 Register the Plugin with Apache Forrest
 
 Fixme (rdg)
 Describe making a request of Forrest devs for 
         inclusion
 
-
+
 Deploying the Plugin
 To deploy the plugin so that others can use it, it must be made 
         available as a zip from the URL indicated in the 
-        plugins.xml file. The plugins build file provides targets 
+        plugins.xml file. The plugins build file provides targets 
         to assist with this task.
 To deploy a plugin simply run the command
-        ant deploy from within the plugin directory.
+        ant deploy from within the plugin directory.
 This command will, by default, deploy to the Apache Forrest web site.
         In order to do this you need commit access to Forrest. If you want to
         deploy your plugin to a different location you 
-        can build the zip of your plugin with ant dist
-        and then copy the zip file from build/dist to wherever
+        can build the zip of your plugin with ant dist
+        and then copy the zip file from build/dist to wherever
         you intend to host the plugin.
 
 Note
 Running this command on any plugin will also deploy any
-        changes to the plugins.xml file. If you are deploying to
+        changes to the plugins.xml file. If you are deploying to
         your own website you will have to request changes to the 
-        plugins.xml and ask the Forrest committers to publish the new
+        plugins.xml and ask the Forrest committers to publish the new
         document.
 
 
 Warning
-Running the deploy or dist targets
-        will always run the test target first. This is to ensure
+Running the deploy or dist targets
+        will always run the test target first. This is to ensure
         that you only deploy working plugins. This adds a little time to
         the deploy cycle, but we feel the peace of mind is worth it.
 
-
+
 Managing the plugins descriptors
 
           The files plugins/plugins.xml and whiteboard/plugins/plugins.xml are
@@ -783,7 +776,7 @@
              Start adding changes notes.

Experimental Functionality

Warning

@@ -796,25 +789,25 @@

Note

For an example of each of these features in use see the - org.apache.forrest.internal.NoteTaking plugin.

+ org.apache.forrest.internal.NoteTaking plugin.

Locationmap

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.

locationmap.xml

We have an issue for the status of locationmap development.

Dispatcher

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 configurable system of defining the contents and look and feel of a site.

Plugins can expose contracts for use in structurer files used within Dispatcher-based sites. In order to do this you should develop your contracts - as normal and place them in PLUGIN_HOME/resources/themes. However, + as normal and place them in PLUGIN_HOME/resources/themes. However, this, by itself, is not sufficient to export your contracts. You will also need to - add the following match to your plugin's locationmap.xml file:

locationmap.xml

     <match pattern="resolvePluginContract.*.**">
       <select type="exists">
@@ -822,39 +815,39 @@
       </select>
     </match>

Of course, you should replace PLUGIN_NAME with the name of +

Of course, you should replace PLUGIN_NAME with the name of 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.

Plugin Properties

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.

Examples

This section will provide some example plugins to help illustrate the steps discussed above.

Input Plugin

Fixme (RDG)

Discuss OpenOffice.org plugin here

Output Plugin

Fixme (RDG)

Discuss s5 plugin here

Internal Plugin

Fixme (RDG)

Discuss IMSManifest plugin here

Summarise the Entire Process

Fixme (open)

Modified: forrest/site/docs_0_80/howto/howto-buildPlugin.pdf URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-buildPlugin.pdf?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== Binary files - no diff available. Modified: forrest/site/docs_0_80/howto/howto-corner-images.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-corner-images.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-corner-images.html (original) +++ forrest/site/docs_0_80/howto/howto-corner-images.html Sun Dec 18 17:31:25 2005 @@ -407,7 +407,7 @@ The procedure outlined below provides an understanding of how corner images are named (the contract) and then shows how to define new colors for these images by modifying the - src/documentation/skinconf.xml of a project. + src/documentation/skinconf.xml of a project.

Understand how corner images are named (the contract)

@@ -437,13 +437,13 @@

The first part - (images/{$name}-{$v-orientation}-{$h-orientation}-{$size}) + (images/{$name}-{$v-orientation}-{$h-orientation}-{$size}) identifies which images is used and how big (width x height) it should be. The second part\ - (-1{$backgroundColor}-2{$strokeColor}-3{$foregroundColor}) + (-1{$backgroundColor}-2{$strokeColor}-3{$foregroundColor}) identifies the coloring of each portion of the image. The input parameter for the second part comes from the color profile of - src/documentation/skinconf.xml. The second part is + src/documentation/skinconf.xml. The second part is easily identifiable through the numbering 1-2-3.

@@ -452,19 +452,19 @@

-images +images: Path to the xslt that creates the corner.
-images/ = {$FORREST_HOME}/main/webapp/skins/common/images/ +images/ = {$FORREST_HOME}/main/webapp/skins/common/images/
-{$name} +{$name}: @@ -473,108 +473,108 @@
-rc.svg.xslt: handles rounded corners +rc.svg.xslt: handles rounded corners

-dc.svg.xslt: handles diagonal 45-degree corners +dc.svg.xslt: handles diagonal 45-degree corners

-name = [rc|dc] +name = [rc|dc]
-e.g. rc +e.g. rc

-{$v-orientation} +{$v-orientation}

Vertical orientation of the corner images (top or bottom).
-v-orientation = [t|b] +v-orientation = [t|b]
-e.g. t +e.g. t

-{$h-orientation} +{$h-orientation}

Horizontal orientation of the corner images (left or right).
-h-orientation = [l|r] +h-orientation = [l|r]
-e.g. r +e.g. r

-{$size} +{$size}

Pixels size of the width and height of the corner image.
-size=x +size=x
-e.g. 5 +e.g. 5

-{$backgroundColor} +{$backgroundColor}

- Any <color name=""/> element in the skinconf.xml (the value="{$color}" + Any <color name=""/> element in the skinconf.xml (the value="{$color}" attribute will be applied).
-e.g. header +e.g. header

-{$strokeColor} +{$strokeColor}

-{$foregroundColor} +{$foregroundColor}

@@ -582,12 +582,12 @@

Modifying the skinconf.xml of your project

- modifying the skinconf.xml of your project (by - default you find it at [project-dir]/src/documentation/). + modifying the skinconf.xml of your project (by + default you find it at [project-dir]/src/documentation/).

- Starting about line 155 you find a <colors> - ... </colors> element with content commented-out: + Starting about line 155 you find a <colors> + ... </colors> element with content commented-out:

 <colors>
@@ -610,8 +610,8 @@

To modify the colors of the corner images, you can either define - your own <color name=.../> elements or uncomment - one of the existing <color name=.../> elements + your own <color name=.../> elements or uncomment + one of the existing <color name=.../> elements and adjust the color value to your needs.

@@ -623,10 +623,10 @@ <color name="tab-selected" value="#FF0000"/>

- This affects all corner images whose {$backgroundColor}, {$strokeColor} or - {$foregroundColor} is set to tab-selected. + This affects all corner images whose {$backgroundColor}, {$strokeColor} or + {$foregroundColor} is set to tab-selected.
- For example, in screen.css (of the "pelt" skin) you find: + For example, in screen.css (of the "pelt" skin) you find:

 #roundbottomsmall {
@@ -636,15 +636,15 @@
 }

- Now the stroke color (-2tab-selected) and the foreground - color (-3tab-selected) are set to red (remember: we - defined #FF0000 as the "color" value of - tab-selected). + Now the stroke color (-2tab-selected) and the foreground + color (-3tab-selected) are set to red (remember: we + defined #FF0000 as the "color" value of + tab-selected).

Modifying .css files

- In addition to the modification of skinconf.xml + In addition to the modification of skinconf.xml you can also modify the respective .css file of your skin.

@@ -671,7 +671,7 @@

Here we have created our own color tags (in the .css file) and - defined the respective values for them (in skinconf.xml). + defined the respective values for them (in skinconf.xml). Now you have color images with a red background and a green foreground. Horrible, isn't it?

Modified: forrest/site/docs_0_80/howto/howto-custom-html-source.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-custom-html-source.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-custom-html-source.html (original) +++ forrest/site/docs_0_80/howto/howto-custom-html-source.html Sun Dec 18 17:31:25 2005 @@ -653,8 +653,8 @@ current context and then assemble the actual expression(s) from it.

In our example the matcher pattern - **/*.html is applied to the request-name - mytest/mybad.html, so we have three variables + **/*.html is applied to the request-name + mytest/mybad.html, so we have three variables altogether:

@@ -753,8 +753,8 @@

In our example the matcher pattern - **body-*.html is applied to the request-name - mytest/body-mybad.html. + **body-*.html is applied to the request-name + mytest/body-mybad.html. Which means that we have three variables altogether:

@@ -856,7 +856,7 @@

-<map:generate src="{project:content.xdocs}{uri}.html" type="html"/> +<map:generate src="{project:content.xdocs}{uri}.html" type="html"/>
Using the html-generator, Forrest reads the html-document from file and uses JTidy to clean up and convert it to xml @@ -869,7 +869,7 @@

-<map:transform src="{forrest:stylesheets}/html2document.xsl"/> +<map:transform src="{forrest:stylesheets}/html2document.xsl"/>
Using the standard stylesheet 'html2document.xsl', this XHTML is transformed into Forrest standard document format. @@ -877,14 +877,14 @@

-<map:transform type="idgen"/> +<map:transform type="idgen"/>
This step generates IDs required for navigation within the page.

-<map:serialize type="xml-document"/> +<map:serialize type="xml-document"/>
Finally the document is serialized as XML and returned to the calling pipeline. Modified: forrest/site/docs_0_80/howto/howto-dev.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-dev.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-dev.html (original) +++ forrest/site/docs_0_80/howto/howto-dev.html Sun Dec 18 17:31:25 2005 @@ -697,7 +697,7 @@

Note that the profiler is not used by default. To switch - it on, edit main/webapp/sitemap.xmap and search + it on, edit main/webapp/sitemap.xmap and search for "profiler". Follow the instructions there to replace the standard "map:pipe" components with the profiling pipes.

@@ -715,7 +715,7 @@

NOTE: Do not forget to turn off the profiler in - main/webapp/sitemap.xmap when finished. + main/webapp/sitemap.xmap when finished.

Using the Cocoon LogTransformer

Modified: forrest/site/docs_0_80/howto/howto-forrest-from-maven.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-forrest-from-maven.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-forrest-from-maven.html (original) +++ forrest/site/docs_0_80/howto/howto-forrest-from-maven.html Sun Dec 18 17:31:25 2005 @@ -390,13 +390,13 @@

Steps

The procedure outlined below describes how to add a goal to your - project's maven.xml that will invoke Forrest's site + project's maven.xml that will invoke Forrest's site target.

Set the FORREST_HOME environment variable

Make sure the FORREST_HOME environment variable points to your Forrest home directory (i.e. the directory that contains - forrest.build.xml) (e.g. C:\opt\apache-forrest-0.7)

+ forrest.build.xml) (e.g. C:\opt\apache-forrest-0.7)

Initialize an Ant environment property at the top of maven.xml

@@ -432,7 +432,7 @@ it's not even necessary to have Ant 1.6 installed separately.

Alternative file

Under $FORREST_HOME/tools/targets/maven.xml +

Under $FORREST_HOME/tools/targets/maven.xml

Modified: forrest/site/docs_0_80/howto/howto-howto.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-howto.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-howto.html (original) +++ forrest/site/docs_0_80/howto/howto-howto.html Sun Dec 18 17:31:25 2005 @@ -456,7 +456,7 @@

An understanding of the How-To document structure. Just use this template document and you will be safe. - Make sure you run 'forrest validate-xdocs' before + Make sure you run 'forrest validate-xdocs' before contributing your document.

Modified: forrest/site/docs_0_80/howto/howto-pdf-tab.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-pdf-tab.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-pdf-tab.html (original) +++ forrest/site/docs_0_80/howto/howto-pdf-tab.html Sun Dec 18 17:31:25 2005 @@ -405,14 +405,14 @@

Steps

The procedure outlined below will define a project - sitemap.xmap and create a new - pdf-tab.xmap. + sitemap.xmap and create a new + pdf-tab.xmap.

Create your project's main sitemap.xmap

If you do not have already a sitemap then create a new empty one in your - src/documentation directory (or wherever + src/documentation directory (or wherever ${project.sitemap-dir} points to).

@@ -444,7 +444,7 @@

Edit the file pdf-tab.xmap

- The <map:match pattern="*.xml"> element + The <map:match pattern="*.xml"> element should look like the following:

@@ -482,7 +482,7 @@

Add the following entry to your site.xml in the - <about> element + <about> element

... 
 <whole_foosite href="pdf-tab.html" label="sub site" />
@@ -502,11 +502,11 @@

This allows you to link to it via a - <link href="site:whole_foosite"> + <link href="site:whole_foosite"> reference.

Add to every element that should be included in the pdf-tab.pdf - the attribute wholesite="true" + the attribute wholesite="true"

 <sample-wiki label="Wiki page" href="wiki-sample.html"
@@ -516,8 +516,8 @@
 Note
 This attribute will be inherited by all children of the element. 
 	 Do not use it in the parent element that contains the 
-	 <whole_foosite href="pdf-tab.html" label="pdf-tab" /> 
-	 as the child (will cause a stack overflow if you do)!!!
+	 <whole_foosite href="pdf-tab.html" label="pdf-tab" /> 
+	 as the child (will cause a stack overflow if you do)!!!
 	
 
 
@@ -526,9 +526,9 @@
       Line 4 of our example
       

       
-<map:parameter name="include" value="//*[@wholesite='true']"/>
+<map:parameter name="include" value="//*[@wholesite='true']"/>
       looks at your site.xml and will match every element containing the
-      wholesite="true" attribute. For example, to use the "samples"
+      wholesite="true" attribute. For example, to use the "samples"
       tab ...
     
 @@ -540,8 +540,8 @@
     
 
       It matches all of the elements that contain
-      wholesite="true"
-      (in our example <samples>
+      wholesite="true"
+      (in our example <samples>
       and its "children") for the content of the pdf file to be generated.
     
  
@@ -556,16 +556,16 @@
     
 
       This example shows that you can as well exclude site(s) from the aggregation 
-      by using the wholesite="false" attribute. This attribute will be as well inherited 
+      by using the wholesite="false" attribute. This attribute will be as well inherited 
       by all children of the element.
     
 
       Line 8 defines the title of the pdf file by taking the content
       of the project-name variable in
-      skinconf.xml and adding some funny text:
+      skinconf.xml and adding some funny text:
       

       
-<map:parameter name="title" value="{conf:project-name}: Still My Foo Site"/>
+<map:parameter name="title" value="{conf:project-name}: Still My Foo Site"/>
     
 
 

Modified: forrest/site/docs_0_80/howto/howto-structurer-contracts.html
URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-structurer-contracts.html?rev=357603&r1=357602&r2=357603&view=diff
==============================================================================
--- forrest/site/docs_0_80/howto/howto-structurer-contracts.html (original)
+++ forrest/site/docs_0_80/howto/howto-structurer-contracts.html Sun Dec 18 17:31:25 2005
@@ -439,7 +439,7 @@
 
       By working on the i18n integration for "pelt" we again encountered the reasons for using the dispatcher. ;-)
       The maintenance problem was to change the captions of the skin features (contracts) to enable
-      support for i18n. The case is that the site2xhtml.xsl has a lot of repeating code. 
+      support for i18n. The case is that the site2xhtml.xsl has a lot of repeating code. 
     
 
       For example the "last-publish"-contract could be found 2 times in the code.  
@@ -491,7 +491,7 @@
 
Explaining the blank forrest:contract
 
         To start a new forrest:contract you can copy the 'blank.ft' from
-        org.apache.forrest.plugin.output.themer/resources/themes/common/html/blank.ft. 
+        org.apache.forrest.plugin.output.themer/resources/themes/common/html/blank.ft. 
       
 
         The 'blank.ft' is a simple xml file with the following code which you can use to base new contracts 
@@ -529,8 +529,8 @@
 </forrest:contract>

- The most important is the name of the contract <forrest:contract name="blank"/>. - This name is the same as the file name of the contract (without file extension) blank.ft. + The most important is the name of the contract <forrest:contract name="blank"/>. + This name is the same as the file name of the contract (without file extension) blank.ft.

Note

@@ -539,7 +539,7 @@

- The <description/> tag needs to be filled in with some information + The <description/> tag needs to be filled in with some information that is explaining the contract to the webdesigner. The better explained the more efficient for the webdesigner to pick the right contract.

@@ -548,19 +548,19 @@ </description>

- In the <usage/> tag we have to explain how the designer can use + In the <usage/> tag we have to explain how the designer can use the contract in his structurer.

<usage><![CDATA[<forrest:contract name="siteinfo-last-published-howto"/>]]></usage>

-<forrest:template name="blank" body="false" head="false"> +<forrest:template name="blank" body="false" head="false"> That leads to the template attribute @body="true" and @head="false". In html a contract can add content to the <body/> or/and <head/> part of <html/>. These values need to be changed when adding an actual template. Besides this, a xsl-template needs to indicate this in the naming. A template that adds content to the - html body needs to end with "-body"!!! + html body needs to end with "-body"!!!

Warning

@@ -599,7 +599,7 @@

Now let us pick up the example we started with and create a "siteinfo-last-published-howto" contract. - Save the blank.ft to {project.home}/src/documentation/resources/themes/common/html/siteinfo-last-published-howto.ft. + Save the blank.ft to {project.home}/src/documentation/resources/themes/common/html/siteinfo-last-published-howto.ft.

Now the maintenance-optimized code (xpath="/html/body/*") was: @@ -670,7 +670,7 @@

Activating the contract

To see whether the new contract works we need to add it to our structurer. - The contract usage contains the contract-tag <forrest:contract name="siteinfo-last-published-howto"/> + The contract usage contains the contract-tag <forrest:contract name="siteinfo-last-published-howto"/> Please see Getting started with the "structurer" for more details.

Modified: forrest/site/docs_0_80/howto/howto-structurer-install.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-structurer-install.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-structurer-install.html (original) +++ forrest/site/docs_0_80/howto/howto-structurer-install.html Sun Dec 18 17:31:25 2005 @@ -421,7 +421,7 @@ The first step is to build and deploy the internal.structurer and the output.themer plugins.

- Run the script etc/structurer.sh *after* you did an svn update. + Run the script etc/structurer.sh *after* you did an svn update.

Otherwise build and deploy them manually. Do your usual 'svn update', then ... @@ -475,8 +475,8 @@

Test your new "dispatcher" based project

Now you have finished the preparation and the setup to finally do - 'forrest run' and - point your browser to http://localhost:8888/ and you will see the default + 'forrest run' and + point your browser to http://localhost:8888/ and you will see the default dispatcher-based site.

@@ -490,7 +490,7 @@ (ls.contracts and/or ls.contracts.project)

- Now point your browser to e.g. http://localhost:8888/ls.contracts.html + Now point your browser to e.g. http://localhost:8888/ls.contracts.html ... On this page you will find all contracts that you can use in your project.

Modified: forrest/site/docs_0_80/howto/howto-view-contracts.html URL: http://svn.apache.org/viewcvs/forrest/site/docs_0_80/howto/howto-view-contracts.html?rev=357603&r1=357602&r2=357603&view=diff ============================================================================== --- forrest/site/docs_0_80/howto/howto-view-contracts.html (original) +++ forrest/site/docs_0_80/howto/howto-view-contracts.html Sun Dec 18 17:31:25 2005 @@ -429,7 +429,7 @@

By working on the i18n integration for "pelt" we again encountered the reasons for using a different system then "old fashion" skins. The maintenance problem was to change the captions of the skin features (contracts) to enable - support for i18n. The case is that the site2xhtml.xsl has a lot of repeating code. + support for i18n. The case is that the site2xhtml.xsl has a lot of repeating code.

For example the "last-publish"-contract could be found 2 times in the code. @@ -481,7 +481,7 @@

Explaining the blank forrest:contract

To start a new forrest:contract you can copy the 'blank.ft' from - org.apache.forrest.plugin.output.themer/resources/themes/common/html/blank.ft. + org.apache.forrest.plugin.output.themer/resources/themes/common/html/blank.ft.

The 'blank.ft' is a simple xml file with the following code which you can use to base new contracts @@ -512,8 +512,8 @@

Note

@@ -522,7 +522,7 @@

@@ -531,19 +531,19 @@ </description>

- In the <usage/> tag we have to explain how the designer can use + In the <usage/> tag we have to explain how the designer can use the contract in his view.

<usage><![CDATA[<forrest:contract name="siteinfo-last-published-howto"/>]]></usage>

-<forrest:template name="blank" body="false" head="false"> +<forrest:template name="blank" body="false" head="false"> That leads to the template attribute @body="true" and @head="false". In xhtml a contract can add content to the <body/> or/and <head/> part of <html/>. These values need to be changed when adding an actual template. Besides this, a xsl-template needs to indicate this in the naming. A template that adds content to the - html body needs to end with "-body"!!! + html body needs to end with "-body"!!!

Note

@@ -575,7 +575,7 @@

Now let us pick up the example we started with and create a "siteinfo-last-published-howto" contract. - Save the blank.ft to {project.home}/src/documentation/resources/templates/siteinfo-last-published-howto.ft. + Save the blank.ft to {project.home}/src/documentation/resources/templates/siteinfo-last-published-howto.ft.

Now the maintenance-optimized code (xpath="/html/body/*") was: @@ -646,7 +646,7 @@

Activating the contract

To see whether the new contract works we need to add it to our view. - The contract usage contains the contract-tag <forrest:contract name="siteinfo-last-published-howto"/> + The contract usage contains the contract-tag <forrest:contract name="siteinfo-last-published-howto"/> Please see Getting started with forrest:view DSL for more details.

1.8. How can I start forrest in debug mode?

3.13. How do I make forrest run listen on a different port?

Setting up passphrase access

Add the mirrors.cgi as a raw file

Run 'forrest' to build your site

status.xml

Component Configuration

Style notes for plugins hosted at forrest.apache.org

Edit the Plugin sitemap file(s)

Components, Actions and Resources

Create the Necessary Resource Files

Create Samples in the Documentation

Testing a Plugin

Testing During Development

Releasing a Plugin

Register the Plugin with Apache Forrest

Deploying the Plugin

Managing the plugins descriptors

Experimental Functionality

Locationmap

Dispatcher

Plugin Properties

Examples

Input Plugin

Output Plugin

Internal Plugin

Further Reading

Summarise the Entire Process

Understand how corner images are named (the contract)

Modifying the skinconf.xml of your project

Modifying .css files

Using the Cocoon LogTransformer

Steps

Set the FORREST_HOME environment variable

Initialize an Ant environment property at the top of maven.xml

Alternative file

Steps

Create your project's main sitemap.xmap

Edit the file pdf-tab.xmap

Explaining the blank forrest:contract

Activating the contract

Test your new "dispatcher" based project

Explaining the blank forrest:contract

Activating the contract