David Crossley wrote:
Ross Gardler wrote:
David Crossley wrote:
Juan Jose Pablos wrote:
I'm interested in seeing this applied to Forrest as Cocoon's
documentation is published via Forrest from Daisy, and I'd like to
update Cocoon's Daisy instance to a new release soon. Therefore, I'd
also like to request if someone could look into updating that file on
the Forrest zone.
Done
Thanks. Cheche has added it to the Forrest trunk SVN.
We need to also deploy the plugin so that the forrestbot
at forrest.zones.apache.org can use it.
No we don't. A while bak I made it so that dev plugins will be copied
from the src tree if possible. See the commit messages at
http://issues.apache.org/jira/browse/FOR-388?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
Gak, i wondered about that. Sorry to spread
that mis-information.
...
We do need to enhance our Howto build plugin docs,
or we each need to re-read them or something. [1]
Quite right, if I'd update the docs you would probably not have missed
the improvement. I think the reason I didn't update the docs was because
this is a "half way" solution to true in-place use of plugins. I
intended to finish the job, but other things have got in the way since.
Probably best to update docs now, no idea when I'll get time to finish this.
$FORREST_HOME/tools/ant/bin/ant deploy
Uh'oh. That does a test build with the Daisy plugin
which fails with ...
...
* [1/16] [16/16] 5.68s 5.5Kb linkmap.html
X [0] cocoon/index.html BROKEN: Unable to get attribute value for
daisy.navigation.docID
...
This is nothing to do with the patch Bruno suplied. It is because the
property daisy.navigation.docID has not been defined in
forrest.properties.xml
...
So perhaps this was already failing before the patch.
Yes, it will have been. It is fixed in SVN now.
Is "local-deploy" necessary now? Yes, see Ross'
comments at the FOR-388 commit messages.
Yes, to recap:
- if the plugin is not present in the forrest/build directory then it
will be locally deployed during "forrest run" (need to test for forrest
war, but it should work for that too).
- if the plugin is then edited and you want to see the results you still
need to do a local-deploy to copy the edits to the running instance
FOR-388 is about true in-place use of plugin srcs. I implemented the
above to:
a) ensure the forrestbot was using the latest dev version (integration
testing)
b) prevent the need to locally deploy plugins after a "build.sh clean"
At what stage do committers do "deploy" and why?
deploy puts a development copy of the plugin on the distibution server.
This means that users who are using the dev version of a plugin will get
the new changes without having to update to SVN head.
Therefore deploy target should only be run when we are sure that the
plugin works correctly. This is why it druns the "test" task efore
deployment.
There is also the release target which will also upload a versioned copy
of the plugin to the server.
Ross
[1] http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html
