Uploaded image for project: 'Forrest'
  1. Forrest
  2. FOR-388

Use plugins in-place if src available

    Details

    • Type: Improvement
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 0.7, 0.8, 0.9
    • Fix Version/s: 0.10-dev
    • Labels:
      None
    • Urgency:
      Normal

      Description

      At present Forrest will attempt to download plugins even if they are available in src form in the local filesystem as part of an SVN checkout.

      Have Forrest mount plugins from designated directories in preference to downloading them wherever possible (need more than posible location for src plugins as some people may be developing their own plugins outside of Forrest)

        Issue Links

          Activity

          Hide
          berni Stefan Bernemann added a comment -
          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!
          Show
          berni Stefan Bernemann added a comment - 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!
          Hide
          rgardler Ross Gardler added a comment -
          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.
          Show
          rgardler Ross Gardler added a comment - 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.
          Hide
          rgardler Ross Gardler added a comment -
          Regarding Stefans proxy problem, you can now configure Forrest to access via an quthenticating proxy. See the proxy properties in forrest.properties.
          Show
          rgardler Ross Gardler added a comment - Regarding Stefans proxy problem, you can now configure Forrest to access via an quthenticating proxy. See the proxy properties in forrest.properties.
          Hide
          rgardler Ross Gardler added a comment -
          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.
          Show
          rgardler Ross Gardler added a comment - 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.
          Hide
          rgardler Ross Gardler added a comment -
          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.
          Show
          rgardler Ross Gardler added a comment - 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.
          Hide
          crossley David Crossley added a comment -
          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.
          Show
          crossley David Crossley added a comment - 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.
          Hide
          rgardler Ross Gardler added a comment -
          Great work Cyriaque
          Show
          rgardler Ross Gardler added a comment - Great work Cyriaque
          Hide
          rgardler Ross Gardler added a comment -
          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.
          Show
          rgardler Ross Gardler added a comment - 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.
          Hide
          rgardler Ross Gardler added a comment -
          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.
          Show
          rgardler Ross Gardler added a comment - 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.
          Hide
          thorsten Thorsten Scherler added a comment -
          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.
          Show
          thorsten Thorsten Scherler added a comment - 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.
          Hide
          rgardler Ross Gardler added a comment -
          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.
          Show
          rgardler Ross Gardler added a comment - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              rgardler Ross Gardler
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development