forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [jira] Commented: (FOR-585) Provide full list of plugins via "Activate Plugins" list
Date Fri, 05 Aug 2005 10:54:26 GMT
Anil Ramnanan wrote:
> Ross Gardler wrote:
> 
> 
>>The wizard will then use this method to get the URL for each of the
>>plugin descriptors and processes them as you intended above.
>>
>>When we change the forrest configuration system we would just need to
>>change the way the forrest.properties are read into the above class.
>>
>>
> 
> I am currently working on getting the plugin descriptors from the
> forrest.properties file. What happens if there are no plugin descriptors
> defined ? Is there somewhere that I can get a default list of
> descriptors from ? I ask because when a new project is seeded
> forrest.plugins.descriptors is not set as active.

If a property does not exist in the project forrest.properties file it 
uses the settings in the users forrest.properties (in their home 
directory), if there is nothing in there then it uses the setting from 
FORREST_HOME/main/webapp/default-forrest.properties

> Also, I noticed the the default descirptors are all located online.When
> user is offline,  where do you get the list of plugins then ?

At this stage you don't. The reason for this is that plugins have a 
different release cycle than Forrest. Meaning that it is updated much 
more frequently than Forrest. Therefore we need to retrieve an up to 
date list.

However, the descriptor file need not be online, any protocol that the 
ANT get task is supported. So a user who finds themselves offline alot 
could change the forest.plugins.descriptors file to include a file:// 
protocol to a downloaded version.

We have, in the past, considered doing a separate download of all the 
plugins to facilitate offline use (probably do four actually, input, 
output, internal, whiteboard). We could also do special downloads for 
certain use cases (views, publishing etc.) But nobody has actually found 
the time to do this yet.

Ultimately, we want to modify the plugins system so that it will use 
local files in preference to remote files if they are present in 
FORREST_HOME/plugins. But again, nobody has actually done this yet. I 
have put most of the infrastructure in place when I did the versioned 
plugin stuff. It should be a relatively small job to finish, but as 
ever, someone needs to have a strong enough itch.

We do *not* want this kind of functionality being written into the 
Eclipse plugin. This should only be an interface to functionality in the 
core Forrest application, there should be no new functionality in it.

----

So what should you do in the Eclipse plugin?

Given that behaviour will change in Forrest you want to implement 
something that will not require modification when Forrest changes. I'd 
therefore suggest that you use Forrests ANT scripts to retrieve the 
relevant descriptor files.

In other words use the fetch-plugins-descriptors task in 
FORREST_HOME/main/targets/plugins.xml to retrieve the descriptors and 
then process the downloaded files that can be found in ${project.temp-dir}.

This way whenever we modify the method for retrieving the descriptors 
(i.e. allow the use of local descriptors if they are available) your 
Eclipse plugin will automatically use the new functionality.

Ross

Mime
View raw message