forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Working - RE: Glossary Plugin FOR-755 - was RE: [jira] Updated: (FOR-639) define terminology for the various aspects of Dispatcher
Date Tue, 04 Apr 2006 03:50:03 GMT
Please don't change the name of the email threads
unless it is a completely new topic. It stuffs up
the email archives.

More below ...

Ross Gardler wrote:
> Gav.... wrote:
> >>From: Ross Gardler
> >>Thorsten Scherler wrote:
> >>> Gav.... escribi?:
> >>>...
> >>>
> >>>>Definitely something wrong I think. I can put in deliberate mistakes,
> >>>>jargon, delete tags, close tags twice and it makes not a bit of
> >>difference.
> >>
> >>>>I can delete the input.xmap file altogether and it cares not, no
> >>difference,
> >>>>the site still builds fine and the glossary.xml file still displays only
> >>>>menus & tabs and no content.
> >>>
> >>>Well that sounds like you should do a build clean (on forrest and your
> >>>plugin), since if you can have an invalid input.xmap that raises the
> >>>suspicion that an old (valid) one is being used (the already deployed
> >>>one).
> >>
> >>Yes, that sounds possible, you need to  do "ant local-deploy" inside the
> >>plugin dir every time you make a change to the plugin code, otherwise
> >>you will be using the old code. See the plugin How To doc.
> >>
> >>(actually, to be totally accurate you don't need to do "ant
> >>local-deploy" after a you clean build Forrest, as if the plugin is not
> >>present it will auto deploy)
> >
> >Blimey, it does seem as though it helps, but to do it every time I made a
> >change was a bit tedious. However I found if I did not, some changes I made
> >would not be effective. 
> It is not necessary to build Forrest after every change, only to do a 
> local-deploy of the plugin you have changed. Thorsten recommended a 
> clean build (as a one off) because it would mean we  knew what state you 
> were in with respect to builds etc.
> You should also note there is also no need to restart Forrest after each 
> local-deploy the plugin for most changes. Some changes, just locationmap 
> and java I think, do require a restart, but most do not.
> There is an issue to use plugins in-place, when complete this will 
> remove the need to do the local-deploy, but it is a work in progress at 
> this point.
> >I also had to ant local-deploy the projectInfo
> >plugin each time.
> There should be no need for this, plugins should be auto-deployed on the 
> first run. The requirement for local-deploy is only for plugins you have 
> changed

I see that howto-buildPlugin is a bit vague on the
need for local-deploy after making changes. I will
try to enhance that.

> >Well, I have had some success now :)
> >
> >I have the plugin working now and the sample glossary.html file works just
> >fine. :)
> Wooo Hooo! Well done.
> >But, (and there usually is a 'but' with me!), I have had to it using
> >workarounds otherwise I just could not get it to go.
> >
> >1. Mentioned previously, 'glossary-v10.dtd' and 'glossary-v10.mod' MUST be
> >in the /xdocs/directory otherwise they are not found and it will not work.
> >If not there, error message is saying they are not found and is pointing to
> >the xdocs directory.
> David hinted at the solution to this earlier on. For an example
> of what to do see:
> In particular look at the catalog.xcat file, just copy the setup here 
> (with obvious changes) and it should all work. Don't forget to remove 
> the DTD's from the XDoc directory or Forrest will continue to pick those up.

The entity resolver, if properly configured via a catalog.xcat
will take precedence.

> This should really be documented in the plugins howto if you get the 
> opportunity to do so whilst working out what to do.

I have updated the howto-buildPlugin doc.


> >2. To get rid of another resource not found error message, I had to put
> >copyover.xsl into the /resources/stylesheets/ directory.
> >
> >Workaround 2. may be a necessity I don't know.
> Leave that in for now. I have  solution in mind, but involves some 
> (minor) work on core, so we'll eave it for now.
> >Should I maybe send in a patch for what I have so you guys aren?t working
> >blind?
> The solution to 1 is easy (once you know how). I'm confident that you'll 
> understand from the above comments, if not then by all means submit a 
> patch with what you have done it is the majority of the work and you no 
> know how to create a plugin ;-)
> Ross

View raw message