You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by ri...@apache.org on 2004/12/01 22:29:47 UTC
svn commit: r109379 - /forrest/trunk/docs-author/status.xml
Author: rick
Date: Wed Dec 1 13:29:46 2004
New Revision: 109379
URL: http://svn.apache.org/viewcvs?view=rev&rev=109379
Log:
Added the text-output plugin
Modified:
forrest/trunk/docs-author/status.xml
Modified: forrest/trunk/docs-author/status.xml
Url: http://svn.apache.org/viewcvs/forrest/trunk/docs-author/status.xml?view=diff&rev=109379&p1=forrest/trunk/docs-author/status.xml&r1=109378&p2=forrest/trunk/docs-author/status.xml&r2=109379
==============================================================================
--- forrest/trunk/docs-author/status.xml (original)
+++ forrest/trunk/docs-author/status.xml Wed Dec 1 13:29:46 2004
@@ -34,7 +34,8 @@
<person name="Reinhard Pötz" email="reinhard@apache.org" id="RP"/>
<person name="Ross Gardler" email="rgardler@apache.org" id="RDG"/>
<person name="Thorsten Scherler" email="thorsten@apache.org" id="TS"/>
-
+ <person name="Rick Tessner" email="rick@apache.org" id="RFT"/>
+
<person name="Volunteer needed" email="forrest-dev@xml.apache.org" id="open"/>
</developers>
@@ -44,6 +45,9 @@
<changes>
<release version="0.7-dev" date="not yet released">
+ <action dev="RFT" type="add" context="plugins" fixes-bug="FOR-125">
+ Added a text-output plugin.
+ </action>
<action dev="RDG" type="add" context="plugins">
Added WYSIWYG editor as a plugin (only works in dynamic webapps)
</action>
Re: Plugin deployment problem (was Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
Ross Gardler wrote:
> Rick Tessner wrote:
>> Looks like the build/dist directory is being created and then deleted
>> right away. A dependency issue in the ant tasks, maybe?
>
>
> Yes, yoiu are right:
>
> init:
> [input] skipping input as property plugin-name has already been set.
> [mkdir] Created dir:
> D:\openSource\forrest\plugins\org.apache.forrest.plugin
> .pdf-output\build\dist
>
> clean:
> [delete] Deleting directory
> D:\openSource\forrest\build\plugins\org.apache.fo
> rrest.plugin.pdf-output
> [delete] Deleting directory
> D:\openSource\forrest\plugins\org.apache.forrest.
> plugin.pdf-output\build\dist
>
> The problem is that dist depends on test and test cleans the build dir.
>
> I have fixed in SVN.
Sweet! Thanks Ross.
--
Rick Tessner
rick at apache dot org
Re: Plugin deployment problem (was Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
Rick Tessner wrote:
> Ross Gardler wrote:
>
>> If this is ready for use please do an "ant deploy" in the plugin
>> directory, this will make the plugin zip available via the forest
>> website.
>
>
> I'm trying to do an "ant deploy" for the text output plugin and I'm
> running into this:
>
> /home/rick/projects/forrest/van/plugins/build.xml:146: Problem creating
> zip:
> /home/rick/projects/forrest/van/plugins/org.apache.forrest.plugin.text-output/build/dist/org.apache.forrest.plugin.text-output.zip
> (No such file or directory) (and the archive is probably corrupt but I
> could not delete it)
>
> Looks like the build/dist directory is being created and then deleted
> right away. A dependency issue in the ant tasks, maybe?
Yes, yoiu are right:
init:
[input] skipping input as property plugin-name has already been set.
[mkdir] Created dir:
D:\openSource\forrest\plugins\org.apache.forrest.plugin
.pdf-output\build\dist
clean:
[delete] Deleting directory
D:\openSource\forrest\build\plugins\org.apache.fo
rrest.plugin.pdf-output
[delete] Deleting directory
D:\openSource\forrest\plugins\org.apache.forrest.
plugin.pdf-output\build\dist
The problem is that dist depends on test and test cleans the build dir.
I have fixed in SVN.
Ross
Plugin deployment problem (was Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
Ross Gardler wrote:
> If this is ready for use please do an "ant deploy" in the plugin
> directory, this will make the plugin zip available via the forest website.
I'm trying to do an "ant deploy" for the text output plugin and I'm
running into this:
/home/rick/projects/forrest/van/plugins/build.xml:146: Problem creating
zip:
/home/rick/projects/forrest/van/plugins/org.apache.forrest.plugin.text-output/build/dist/org.apache.forrest.plugin.text-output.zip
(No such file or directory) (and the archive is probably corrupt but I
could not delete it)
Looks like the build/dist directory is being created and then deleted
right away. A dependency issue in the ant tasks, maybe?
--
Rick Tessner
rick at apache dot org
Re: Plugin release process (was Re: svn commit: r109379 - /forrest/trunk/docs-author/status.xml)
Posted by David Crossley <cr...@apache.org>.
Rick Tessner wrote:
> Ross Gardler wrote:
[snip]
>
>> At present there is no release process for plugins. We have simply
>> been releasing them when new features have been added.
>
>
> Okay. I guess this plugin should follow the naming convention as well.
> I'd like to do that before I deploy it. If I understand the convention
> correctly, it should be:
>
> org.apache.forrest.plugin.text-output
>
>> However, we will need to manage the official release of plugins (which
>> should also include a publishing of the plugin documentation to the
>> website).
>>
>> How should we manage this process?
>
>
> At this point, I'm not sure what the manual process would be either.
> Plugins would certainly have a different release cycle than Forrest itself.
>
> I'll just start putting together a list that is by no means
> comprehensive and hopefully others will add/correct this list:
>
> 1. Identify the Forrest releases that the plugin is compatible with.
> 2. Deploy the plugin to the release site somehow identifying Forrest
> version compatability.
SVN revision number, or perhaps svn tag name.
There is an old discussion on filename conventions
in the dev mail archive, not yet xdocs.
> 3. Updating the plugin documentation for each release it is compatible
> with.
> 4. Announcing availability of updated / new plugin.
Thanks for starting this list. Looks fine.
>> PS Thanks for your great work on this Rick, I will shortly need to
>> update the site I wrote the original xdoc2txt stuff for. It is superb
>> that I won't have to refine the code before the next update. (I love
>> Open Source)
>
> Thanks and yup, this Open Source stuff is awesome!
Yippee, it is ever so empowering.
--David
Re: Validation error with Crimson
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
>> Rick Tessner wrote:
>>> David Crossley wrote:
>>>
>>>> Am i stating the obvious to say that it is using the
>>>> wrong classpath and getting parsers and such, from the
>>>> JDK instead?
>>>
>>> Hmmm ... how does Ant know that it _should_ be using a parser other
>>> than crimson? I believe in JDK 1.4.x, the default parser is crimson.
>>>
>>> But then, why would the xml validation work when not called via <ant>
>>> ... ???
>>
>> Because in the rest of the build, we deliberately
>> set the classpath to our own copies of lib/*.jar
>>
>> At Cocoon we call forrest (still forrest-0.5.1) via
>> the cocoon build.xml where we set the classpath before
>> doing that call.
>
>
> OK, Rick, can you try and patch the plugin build file by looking at the
> Cocoon build.xml file (Ican't reproduce this behaviour).
It is probably that our forrest build system
needs to set the classpath at an earlier stage.
Also people need to use a modern version of Ant.
Rather than doing 'ant test'
i did '$FORREST_HOME/tools/ant/bin/ant test'
and received the same failure.
There are related issues about integrating forrest
into other project build files. We have a number
of issues described in Jira, including one suggestion
from Upayavira about using the Cocoon Ant task.
We are also having problems at cocoon-2.2 with
trying to upgrade to forrest-0.6 due to the way we
are calling it via the Ant build file. There are
some clashing names for ant targets and ant variables.
Sounds like it is time for an overhaul of our
build system.
--David
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
Rick Tessner wrote:
> Rick Tessner wrote:
>
>> It's definitely a classpath issue.
<snip/>
> Patch has been committed.
Cool. Thanks Rick. I've posted a message in the thread on the user list
asking them to test your solution.
> Don't know why this would have been working under WinXP w/ cygwin for
> Ross tho ... :confused:
Well I was confused before you fixed it and I'm still confused now, but
you fixed it so I don't care ;-)
Ross
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
Rick Tessner wrote:
> It's definitely a classpath issue. Now, the interesting thing is if I
> explicity set the CLASSPATH environment variable to contain all the jars
> in $FORREST_HOME/lib/*/*.jar and then run the "ant test" it works just
> fine (well, except for a character encoding problem but that's a
> different unrelated problem).
>
> I then unset the classpath and run the "ant test" and it fails as expected.
>
> Okay, so definitely classpath.
>
> Edit the main/targets/validate.xml and add the classpathref attribute to
> the <xmlvalidate> task. Give it a value of "forrest.cp" which is <path>
> set up in the <-prepare-classpath> task in main/forrest.build.xml (it is
> this build file that is referenced by the plugins/build.xml).
>
> Run the "ant test" again. Fails with the same problem.
>
> Okay, try explicitly setting the <classpath> element as a child of
> <xmlvalidate>.
>
> Run the "ant test" again. Fails again, same problem.
Looks like the piece I was missing what that the <xmlvalidate> task not
only required the classpathref (or classpath) attribute but also the
classname attribute to define explicitly which class to use for the
parser. (Found by walking through the ant source ...)
So, on the <xmlvalidate> task, I set the classpathref="forrest.cp" and
classname="org.apache.xerces.parsers.SAXParser" and ta da, it works.
Patch has been committed.
It looks like Ant determines on startup what XML parser it has and the
<xmlvalidate> task will use that regardless of what it's told in terms
of the classpath. Hence, the necessity of explicitly telling it the
classname as well.
Don't know why this would have been working under WinXP w/ cygwin for
Ross tho ... :confused:
--
Rick Tessner
rick at apache dot org
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
Rick Tessner wrote:
> Ross Gardler wrote:
>
>> David Crossley wrote:
>>
>>>
>>> At Cocoon we call forrest (still forrest-0.5.1) via
>>> the cocoon build.xml where we set the classpath before
>>> doing that call.
>>
>>
>>
>> OK, Rick, can you try and patch the plugin build file by looking at
>> the Cocoon build.xml file (Ican't reproduce this behaviour).
>
>
> Will do.
Me thinks I'm loosing my mind ...
It's definitely a classpath issue. Now, the interesting thing is if I
explicity set the CLASSPATH environment variable to contain all the jars
in $FORREST_HOME/lib/*/*.jar and then run the "ant test" it works just
fine (well, except for a character encoding problem but that's a
different unrelated problem).
I then unset the classpath and run the "ant test" and it fails as expected.
Okay, so definitely classpath.
Edit the main/targets/validate.xml and add the classpathref attribute to
the <xmlvalidate> task. Give it a value of "forrest.cp" which is <path>
set up in the <-prepare-classpath> task in main/forrest.build.xml (it is
this build file that is referenced by the plugins/build.xml).
Run the "ant test" again. Fails with the same problem.
Okay, try explicitly setting the <classpath> element as a child of
<xmlvalidate>.
Run the "ant test" again. Fails again, same problem.
I think I'm stuck. Will try again with fresh eyes tomorrow. :(
--
Rick Tessner
rick at apache dot org
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@onnadayr.ca>.
Ross Gardler wrote:
> David Crossley wrote:
>>
>> At Cocoon we call forrest (still forrest-0.5.1) via
>> the cocoon build.xml where we set the classpath before
>> doing that call.
>
>
> OK, Rick, can you try and patch the plugin build file by looking at the
> Cocoon build.xml file (Ican't reproduce this behaviour).
Will do.
--
rick@onnadayr.ca
IT Firefighting and Prevention
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Rick Tessner wrote:
>
>> David Crossley wrote:
>>
>>>
>>> Am i stating the obvious to say that it is using the
>>> wrong classpath and getting parsers and such, from the
>>> JDK instead?
>>
>>
>>
>> Hmmm ... how does Ant know that it _should_ be using a parser other
>> than crimson? I believe in JDK 1.4.x, the default parser is crimson.
>>
>> But then, why would the xml validation work when not called via <ant>
>> ... ???
>
>
> Because in the rest of the build, we deliberately
> set the classpath to our own copies of lib/*.jar
>
> At Cocoon we call forrest (still forrest-0.5.1) via
> the cocoon build.xml where we set the classpath before
> doing that call.
OK, Rick, can you try and patch the plugin build file by looking at the
Cocoon build.xml file (Ican't reproduce this behaviour).
Ross
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by David Crossley <cr...@apache.org>.
Rick Tessner wrote:
> David Crossley wrote:
>
>>
>> Am i stating the obvious to say that it is using the
>> wrong classpath and getting parsers and such, from the
>> JDK instead?
>
>
> Hmmm ... how does Ant know that it _should_ be using a parser other than
> crimson? I believe in JDK 1.4.x, the default parser is crimson.
>
> But then, why would the xml validation work when not called via <ant>
> ... ???
Because in the rest of the build, we deliberately
set the classpath to our own copies of lib/*.jar
At Cocoon we call forrest (still forrest-0.5.1) via
the cocoon build.xml where we set the classpath before
doing that call.
--David
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@onnadayr.ca>.
David Crossley wrote:
>
> Am i stating the obvious to say that it is using the
> wrong classpath and getting parsers and such, from the
> JDK instead?
Hmmm ... how does Ant know that it _should_ be using a parser other than
crimson? I believe in JDK 1.4.x, the default parser is crimson.
But then, why would the xml validation work when not called via <ant>
... ???
--
rick@onnadayr.ca
IT Firefighting and Prevention
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
Rick Tessner wrote:
> Ross Gardler wrote:
>
>> I cannot reproduce this bug (windows XP, JDK1.4.2, cygwin) so it would
>> appear to be a Linux thing.
>
>
> Hi Ross,
>
> Quick question, do you have an environment variable called
> LOCALCLASSPATH set at all when running this under cygwin?
No (quick answer :-))
Ross
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
Ross Gardler wrote:
> I cannot reproduce this bug (windows XP, JDK1.4.2, cygwin) so it would
> appear to be a Linux thing.
Hi Ross,
Quick question, do you have an environment variable called
LOCALCLASSPATH set at all when running this under cygwin?
--
Rick Tessner
rick at apache dot org
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
Rick Tessner wrote:
> David Crossley wrote:
>
> <snip/>
>
>> Am i stating the obvious to say that it is using the
>> wrong classpath and getting parsers and such, from the
>> JDK instead?
>
>
> It sure looks that way, don't it? My classpath is not set, etc. Oh and
> my java is 1.4.2_03 under Linux (not using that 1.5 yet).
>
> Looking at the build.xml for the plugins,
> $FORREST_HOME/plugins/build.xml, the "site" target is being called via
> <ant> from there. So, this appears to be related to the thread in the
> user list regarding calling forrest from ANT ...
>
Yes, that will be the connection because the user got this problem when
I advised him to use the same method of calling the forrest site target
as the one I use in the plugin build.xml file.
I cannot reproduce this bug (windows XP, JDK1.4.2, cygwin) so it would
appear to be a Linux thing.
Ross
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
David Crossley wrote:
<snip/>
> Am i stating the obvious to say that it is using the
> wrong classpath and getting parsers and such, from the
> JDK instead?
It sure looks that way, don't it? My classpath is not set, etc. Oh and
my java is 1.4.2_03 under Linux (not using that 1.5 yet).
Looking at the build.xml for the plugins,
$FORREST_HOME/plugins/build.xml, the "site" target is being called via
<ant> from there. So, this appears to be related to the thread in the
user list regarding calling forrest from ANT ...
--
Rick Tessner
rick at apache dot org
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by David Crossley <cr...@apache.org>.
Rick Tessner wrote:
> Ross Gardler wrote:
>
>> Just to save someone a little time, I just did "svn up" and
>> "./build.sh test" with no problems so it is something specific with
>> these two setups.
>>
>> Rick, can you do ./build test?
>
> Do you mean from $FORREST_HOME/main? If so, yup, that "./build.sh test"
> worked just fine.
Yes, that is it. Works for me too.
> If I then set my ANT_HOME=$FORREST_HOME/tools/ant and add $ANT_HOME/bin
> to my PATH and
>
> cd $FORREST_HOME/plugins/text-output (or any plugin)
> ant test
>
> I get the xmlvalidation failure.
Am i stating the obvious to say that it is using the
wrong classpath and getting parsers and such, from the
JDK instead?
--David
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@apache.org>.
Ross Gardler wrote:
>
> Just to save someone a little time, I just did "svn up" and "./build.sh
> test" with no problems so it is something specific with these two setups.
>
> Rick, can you do ./build test?
Do you mean from $FORREST_HOME/main? If so, yup, that "./build.sh test"
worked just fine.
If I then set my ANT_HOME=$FORREST_HOME/tools/ant and add $ANT_HOME/bin
to my PATH and
cd $FORREST_HOME/plugins/text-output (or any plugin)
ant test
I get the xmlvalidation failure.
--
Rick Tessner
rick at apache dot org
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Rick Tessner <ri...@onnadayr.ca>.
Ross Gardler wrote:
>
> Just to save someone a little time, I just did "svn up" and "./build.sh
> test" with no problems so it is something specific with these two setups.
>
> Rick, can you do ./build test?
Do you mean from $FORREST_HOME/main? If so, yup, that "./build.sh test"
worked just fine.
If I then set my ANT_HOME=$FORREST_HOME/tools/ant and add $ANT_HOME/bin
to my PATH and
cd $FORREST_HOME/plugins/text-output (or any plugin)
ant test
I get the xmlvalidation failure.
--
rick@onnadayr.ca
IT Firefighting and Prevention
Re: Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Rick Tessner wrote:
>
>> Ross Gardler wrote:
>>
>>> If this is ready for use please do an "ant deploy" in the plugin
>>> directory, this will make the plugin zip available via the forest
>>> website.
>>
>>
>>
>> Will do. I've been trying the "ant test" and I get this very odd
>> message during "validate-xdocs":
>>
>> -- begin message --
>> validate-xdocs:
>>
>> BUILD FAILED
>> /home/rick/projects/forrest/van/plugins/build.xml:133: The following
>> error occurred while executing this line:
>> /home/rick/projects/forrest/van/main/targets/validate.xml:143: Parser
>> org.apache.crimson.parser.XMLReaderImpl doesn't recognize feature
>> http://apache.org/xml/features/validation/dynamic
>>
>> -- end message --
>>
>> My CLASSPATH is not set, FORREST_HOME points to the right place (in my
>> case, /home/rick/projects/forrest/van) and "forrest site" and "forrest
>> local-deploy" work just fine ... I'm at a bit of a loss ATM. :(
>
>
> There is a thread on the user list that I stopped at when this very
> message was reported. I thought it was something specific to their setup
> (the original problem was with running Forrest from ANT). I don't have
> the time to look into it and so gave him a work around and hoped someone
> else would jump in.
>
> Does anyone have any idea why this is suddenly happening?
Just to save someone a little time, I just did "svn up" and "./build.sh
test" with no problems so it is something specific with these two setups.
Rick, can you do ./build test?
Ross
Validation error with Crimson (WAS: Re: Plugin release process)
Posted by Ross Gardler <rg...@apache.org>.
Rick Tessner wrote:
> Ross Gardler wrote:
>
>> If this is ready for use please do an "ant deploy" in the plugin
>> directory, this will make the plugin zip available via the forest
>> website.
>
>
> Will do. I've been trying the "ant test" and I get this very odd
> message during "validate-xdocs":
>
> -- begin message --
> validate-xdocs:
>
> BUILD FAILED
> /home/rick/projects/forrest/van/plugins/build.xml:133: The following
> error occurred while executing this line:
> /home/rick/projects/forrest/van/main/targets/validate.xml:143: Parser
> org.apache.crimson.parser.XMLReaderImpl doesn't recognize feature
> http://apache.org/xml/features/validation/dynamic
>
> -- end message --
>
> My CLASSPATH is not set, FORREST_HOME points to the right place (in my
> case, /home/rick/projects/forrest/van) and "forrest site" and "forrest
> local-deploy" work just fine ... I'm at a bit of a loss ATM. :(
There is a thread on the user list that I stopped at when this very
message was reported. I thought it was something specific to their setup
(the original problem was with running Forrest from ANT). I don't have
the time to look into it and so gave him a work around and hoped someone
else would jump in.
Does anyone have any idea why this is suddenly happening?
Ross
Re: Plugin release process (was Re: svn commit: r109379 - /forrest/trunk/docs-author/status.xml)
Posted by Dave Brondsema <da...@brondsema.net>.
Rick Tessner wrote:
> Ross Gardler wrote:
>> However, we will need to manage the official release of plugins (which
>> should also include a publishing of the plugin documentation to the
>> website).
>>
>> How should we manage this process?
>
>
> At this point, I'm not sure what the manual process would be either.
> Plugins would certainly have a different release cycle than Forrest itself.
>
> I'll just start putting together a list that is by no means
> comprehensive and hopefully others will add/correct this list:
>
> 1. Identify the Forrest releases that the plugin is compatible with.
> 2. Deploy the plugin to the release site somehow identifying Forrest
> version compatability.
> 3. Updating the plugin documentation for each release it is compatible
> with.
> 4. Announcing availability of updated / new plugin.
>
Specifying version compatibility for skins was discussed quite a while
ago and I recall there being no satisfactory solutions (i.e. one where
we could just put files on the webserver without any sort of database,
and also handle all the combinations of version differences).
I think this is a prime example of a situation where we should look at
the way Eclipse plugins and/or Firefox extensions handle version
compatibility.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: Plugin release process (was Re: svn commit: r109379 - /forrest/trunk/docs-author/status.xml)
Posted by Rick Tessner <ri...@apache.org>.
Ross Gardler wrote:
> If this is ready for use please do an "ant deploy" in the plugin
> directory, this will make the plugin zip available via the forest website.
Will do. I've been trying the "ant test" and I get this very odd
message during "validate-xdocs":
-- begin message --
validate-xdocs:
BUILD FAILED
/home/rick/projects/forrest/van/plugins/build.xml:133: The following
error occurred while executing this line:
/home/rick/projects/forrest/van/main/targets/validate.xml:143: Parser
org.apache.crimson.parser.XMLReaderImpl doesn't recognize feature
http://apache.org/xml/features/validation/dynamic
-- end message --
My CLASSPATH is not set, FORREST_HOME points to the right place (in my
case, /home/rick/projects/forrest/van) and "forrest site" and "forrest
local-deploy" work just fine ... I'm at a bit of a loss ATM. :(
> At present there is no release process for plugins. We have simply been
> releasing them when new features have been added.
Okay. I guess this plugin should follow the naming convention as well.
I'd like to do that before I deploy it. If I understand the
convention correctly, it should be:
org.apache.forrest.plugin.text-output
> However, we will need to manage the official release of plugins (which
> should also include a publishing of the plugin documentation to the
> website).
>
> How should we manage this process?
At this point, I'm not sure what the manual process would be either.
Plugins would certainly have a different release cycle than Forrest itself.
I'll just start putting together a list that is by no means
comprehensive and hopefully others will add/correct this list:
1. Identify the Forrest releases that the plugin is compatible with.
2. Deploy the plugin to the release site somehow identifying Forrest
version compatability.
3. Updating the plugin documentation for each release it is compatible
with.
4. Announcing availability of updated / new plugin.
> PS Thanks for your great work on this Rick, I will shortly need to
> update the site I wrote the original xdoc2txt stuff for. It is superb
> that I won't have to refine the code before the next update. (I love
> Open Source)
Thanks and yup, this Open Source stuff is awesome!
--
Rick Tessner
rick at apache dot org
Plugin release process (was Re: svn commit: r109379 - /forrest/trunk/docs-author/status.xml)
Posted by Ross Gardler <rg...@apache.org>.
rick@apache.org wrote:
> Author: rick
> Date: Wed Dec 1 13:29:46 2004
> New Revision: 109379
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=109379
> Log:
> Added the text-output plugin
> Modified:
> forrest/trunk/docs-author/status.xml
If this is ready for use please do an "ant deploy" in the plugin
directory, this will make the plugin zip available via the forest website.
At present there is no release process for plugins. We have simply been
releasing them when new features have been added.
However, we will need to manage the official release of plugins (which
should also include a publishing of the plugin documentation to the
website).
How should we manage this process?
Ross
PS Thanks for your great work on this Rick, I will shortly need to
update the site I wrote the original xdoc2txt stuff for. It is superb
that I won't have to refine the code before the next update. (I love
Open Source)