procedure when patching plugins

[David Crossley <cr...@apache.org>]

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.

Actually i was confused by local behaviour. I am
only doing 'build clean' when necessary. Forrestbot
on the zone is cleaning every hour, so  it gets the
new plugin by itself. Nice.

We do need to enhance our Howto build plugin docs,
or we each need to re-read them or something. [1]

> > $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
> > ...
> >
> > Sorry i don't know what that means. Bruno's patch
> > is related to Daisy IDs.
> 
> 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
>
> I'll raise an issue.

So perhaps this was already failing before the patch.

We need to follow a procedure when patching plugins:
Do '$FORREST_HOME/tools/ant/bin/ant test' beforehand.
Apply the patch.
Do '$FORREST_HOME/tools/ant/bin/ant test' again.

Is "local-deploy" necessary now? Yes, see Ross'
comments at the FOR-388 commit messages.

At what stage do committers do "deploy" and why?

[1] http://forrest.apache.org/docs/dev/howto/howto-buildPlugin.html

-David

> > So until we fix this (and another error) we cannot deploy
> > the Daisy plugin.
> 
> See above, no problem. It should still work, so Bruno can go ahead and 
> update the Cocoon Daisy instance. The forrestbot will tell us if there 
> is a problem. I can't see any issues wth the patch.
> 
> Ross

Re: procedure when patching plugins

[Ross Gardler <rg...@apache.org>]

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