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
