forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Working - RE: Glossary Plugin FOR-755 - was RE: [jira] Updated: (FOR-639) define terminology for the various aspects of Dispatcher
Date Mon, 03 Apr 2006 18:10:34 GMT
Gav.... wrote:
> 
>>-----Original Message-----
>>From: Ross Gardler [mailto:rgardler@apache.org]
>>Sent: Monday, 3 April 2006 8:00 PM
>>To: dev@forrest.apache.org
>>Subject: Re: Glossary Plugin FOR-755 - was RE: [jira] Updated: (FOR-639)
>>define terminology for the various aspects of Dispatcher
>>
>>Thorsten Scherler wrote:
>>
>>>El lun, 03-04-2006 a las 17:00 +0800, 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

...

> 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:

http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.input.listLocations/resources/schema/

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.

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

> 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


Mime
View raw message