Anil Ramnanan wrote:
Ross Gardler (JIRA) wrote:
Ross Gardler commented on FOR-585:
----------------------------------
I've applied patch ActivatePluginPatch270705.diff but I'm not closing
this issue as the current solution causes a maintenance problem since
all plugin names are hard coded into the java code. We need to extract
those from the plugins.xml file.
I am going to use the plugins.xml file located in _FORREST_HOME/plugins
to get the list of available plugins. Is this the right location ? I ask
because I see taht there is a plugin.descriptors properties in
forrest.properties which points to
http://forrest.apache.org/plugins/plugins.xml.
The current solution is fine for now. Don't get too bogged down in
detail, you have much to do for GSoC and this goes beyond the scope of
your original proposal. I have added it to the issue tracker as a
reminder of potential improvements not as an "instruction" for any
particular dev.
That said, please feel free to go ahead and implement it if you want to
scratch the itch, as long as you understand this is not something that I
(with my GSoC mentor hat on) consider a requirement for your GSoC
proposal. If you choose not to implement this please add a comment to
the issue linking to this thread in the archives as you have raised some
important points that we should maintain.
Now, to answer your question...
The plugins.descriptors file can actually take multiple values, i.e.
there can be more than one descriptor. So you should really take this
property and interpret all the available plugins in the various descriptors.
The reason for multiple descriptors is that people may build custom
plugins for their own site.
Furthermore, you should use the published version because plugins have a
different release cycle to that of Forrest. Hence there may be more
plugins available than are specified in the local
FORREST_HOME/plugins/plugins.xml file.
Finally, that particular file is not a part of the binary distribution
of Forrest, so your solution would only work with source distributions.
How does this sound as a solution:
We create a forrestProperties.java file which will read in the values
from forrest.properties and make them available via appropriate methods,
for example:
/**
* Retrieve a list of plugin descriptor files used by this site.
* @return an array of URLs pointing to plugin descriptor files
*/
public Array getPluginDescriptorURLs();
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.
Ross
