forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: procedure when patching plugins
Date Thu, 02 Mar 2006 15:57:55 GMT
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

Mime
View raw message