You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by cr...@apache.org on 2011/01/10 02:55:46 UTC
svn commit: r1057071 -
/forrest/trunk/site-author/content/xdocs/docs_0_90/howto/howto-buildPlugin.xml
Author: crossley
Date: Mon Jan 10 01:55:46 2011
New Revision: 1057071
URL: http://svn.apache.org/viewvc?rev=1057071&view=rev
Log:
Add an "explain' section to the "descriptor" section, and move "register" sectio
n up.
Link to a good discussion of the deployment procedure and the difference between
"deploy" and "release" build targets. Thanks Ross.
Modified:
forrest/trunk/site-author/content/xdocs/docs_0_90/howto/howto-buildPlugin.xml
Modified: forrest/trunk/site-author/content/xdocs/docs_0_90/howto/howto-buildPlugin.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/docs_0_90/howto/howto-buildPlugin.xml?rev=1057071&r1=1057070&r2=1057071&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/docs_0_90/howto/howto-buildPlugin.xml (original)
+++ forrest/trunk/site-author/content/xdocs/docs_0_90/howto/howto-buildPlugin.xml Mon Jan 10 01:55:46 2011
@@ -363,57 +363,75 @@
</section>
<section id="descriptor">
<title>Managing the plugins descriptors</title>
- <p>
- The files plugins/plugins.xml and
- whiteboard/plugins/whiteboard-plugins.xml are the "Plugins Descriptor"
- files. Each plugin is described with its name, purpose, location, and
- version information. These descriptors are deployed to the forrest
- website.
- </p>
- <p>
- Each plugin has a build.xml file which defines its version
- information. Please keep that synchronised with the plugins.xml files.
- Later
- <a href="http://issues.apache.org/jira/browse/FOR-533">FOR-533</a>
- will generate this from the various build.xml files.
- </p>
- <p>
- The Apache Forrest committers manage these files in SVN and publish
- them as needed. Here are some notes.
- </p>
- <p>
- When a plugin gains new functionality, then it will be dependent on a
- more recent version of Forrest. Deploy the plugin one final time
- before implementing the new work. For example, if current release is
- 0.7 then ...
- </p>
- <ul>
- <li>Review the docs and ensure any version numbers in text are "0.7"</li>
- <li>Edit the plugin's descriptors to ensure that the "forrestVersion" is 0.7 and that the "version" is appropriate. </li>
- <li>Ensure that the "website" parameter includes "pluginDocs/plugins_0_70"</li>
- <li>Edit status.xml to set the release date. Ensure that the changes notes are complete.</li>
- </ul>
- <p>
- Now the plugin gains functionality that binds it to 0.8-dev (e.g.
- converted to use locationmap) so ...
- </p>
- <ul>
- <li>Review the docs and ensure any version numbers in text are
- "0.8"</li>
- <li>Edit the plugin's descriptors to ensure that the "forrestVersion" is
- 0.8 and that the "version" is incremented. </li>
- <li>Ensure that the "website" parameter includes "pluginDocs/plugins_0_80"</li>
- <li>Edit status.xml to add a new section and set the release date.
- Start adding changes notes.</li>
- </ul>
- </section>
- <section id="release">
- <title>Releasing a Plugin</title>
+ <section id="explain-descriptor">
+ <title>Explanation</title>
+ <p>
+ The files plugins/plugins.xml and
+ whiteboard/plugins/whiteboard-plugins.xml are the "Plugins Descriptor"
+ files. Each plugin is described with its name, purpose, location, and
+ version information. These descriptors are deployed to the forrest
+ website.
+ </p>
+ <p>
+ Each plugin has a build.xml file which defines its version
+ information. Please keep that synchronised with the plugins.xml files.
+ Later
+ <a href="http://issues.apache.org/jira/browse/FOR-533">FOR-533</a>
+ will generate this from the various build.xml files.
+ </p>
+ <p>
+ The Apache Forrest committers manage these files in SVN and publish
+ them as needed. Here are some notes.
+ </p>
+ <p>
+ When a plugin gains new functionality, then it will be dependent on a
+ more recent version of Forrest. Deploy the plugin one final time
+ before implementing the new work. For example, if current release is
+ 0.7 then ...
+ </p>
+ <ul>
+ <li>Review the docs and ensure any version numbers in text are "0.7"</li>
+ <li>Edit the plugin's descriptors to ensure that the "forrestVersion" is 0.7 and that the "version" is appropriate. </li>
+ <li>Ensure that the "website" parameter includes "pluginDocs/plugins_0_70"</li>
+ <li>Edit status.xml to set the release date. Ensure that the changes notes are complete.</li>
+ </ul>
+ <p>
+ Now the plugin gains functionality that binds it to 0.8-dev (e.g.
+ converted to use locationmap) so ...
+ </p>
+ <ul>
+ <li>Review the docs and ensure any version numbers in text are
+ "0.8"</li>
+ <li>Edit the plugin's descriptors to ensure that the "forrestVersion" is
+ 0.8 and that the "version" is incremented. </li>
+ <li>Ensure that the "website" parameter includes "pluginDocs/plugins_0_80"</li>
+ <li>Edit status.xml to add a new section and set the release date.
+ Start adding changes notes.</li>
+ </ul>
+ </section>
<section id="register">
<title>Register the Plugin with Apache Forrest</title>
<fixme author="open">
- Describe making a request of Forrest devs for inclusion
+ Describe making a request of Forrest devs for inclusion.
+ In the meantime just ask on the dev mail list.
+ </fixme>
+ </section>
+ </section>
+ <section id="release">
+ <title>Deploying and Releasing a Plugin</title>
+ <section id="explain-deploy">
+ <title>Explanation</title>
+ <fixme author="open">
+ Describe "deploy" and "release" and when/how to use each.
+ In the meantime, there are some other useful mail threads and notes:
</fixme>
+ <ul>
+ <li>
+ <a href="http://s.apache.org/ou">Re: plugins deployment problem</a>
+ which has a good description of how the system works.
+ </li>
+ <li>a text document at $FORREST_HOME/plugins/RELEASE_PROCESS.txt</li>
+ </ul>
</section>
<section id="deploy">
<title>Deploying the Plugin</title>