|
[
Permlink
| « Hide
]
Stefan Bernemann added a comment - 14/Dec/04 01:22 PM
It seems to me that I cannot install plugins behind an authenticating proxy (or did I miss some options?). In this case, this issue becomes very important!
The plugins system uses the GET task in ANT to retrieve the plugins, I believe that this task uses the Operating Systems defailt settings for proxy configuration (although I may be wrong).
Alternatively, you can manually install the plugins you need. If you have the source tree then simply cd into FORREST_HOME/plugins/PLUGIN_NAME and run "ant local-deploy". If you do not have the src tree then download the plugin zip file from the location indicated in http://forrest.apache.org/plugins/plugins.xml and unztip it into FORREST_HOME/build/plugins (this information is now in the message displayed if a plugin fails to install). OF course, these are all just workarounds, implementing the in-place functioning of plugins is the best solution. Regarding Stefans proxy problem, you can now configure Forrest to access via an quthenticating proxy. See the proxy properties in forrest.properties.
Currently plugins are used from the build directory, if we do a Forrest clean it removes the plugins thus causing someone to have to download again, this would not be necessary if the plugins were used inplace and the src was available.
I've put a "half-way" solution to this in place.
Plugins are not used in place, they still need to be deployed. However, during startup Forrest will now look in the local src directories before trying to download (for unversioned plugins only, versioned plugins are still downloaded from a remote repository). Forrestbot installations will now use the local src. This means that our continuous integration tests on the zone will use the most recent development version of the plugin, rather than the most recent release. Another benefit is that we can now provide a separate zip of plugins and whiteboard plugins for users with problems with the auto-download mechanism, we will simply direct them to download the plugins zips and install them in their FORREST_HOME directory. However, this is not a final solution, it should be considered a hack and removed when we implement prooper in-place use of plugins. See the commits for this issue to evaluate the code that will need to be removed. The target "configure-plugin" in main/targets/plugins.xml calls "configure-plugin-locationmap" at runtime to add a plugin locationmap if the plugin supplies one. A locationmap should be able to be supplied subsequently without restarting Forrest.
Reopening as the current solution does not provide "in place" use. That is it still deploys the plugin code to the build directory rather than using it from the source directory. Therefore, plugins still need to be deployed (or Forrest restarted) if they have been edited.
Although it shoul dbe noted the current solution elegantly solves the problem of installing plugins when network connection is poor. Changing priority and target release. The current solution is a massive improvement and is worthy of a minor release. We'll finish the job for the next release.
We need to be aware that some parts of plugins need to be builded first and then deployed because they e.g. provide java classes. Meaning that at least the src/java needs to be deployed where xsl, sitemaps, etc. can be used copyless.
With respect to java classes -
Just add them to the classpath i their standard location. No need to deploy them, just ensure they are compiled. This does cause a problem with reloading edited java files - but I plan to explore the CompilingClassLoader in Cocoon as soon as I get a chance. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Reopened
Major
Use plugins in-place if src available
