Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 0.10-dev
    • Labels:
      None
    • Urgency:
      Normal

      Description

      The information in the plugins.xml file would be better kept in the plugin directory and added to the plugins.xml file when deployed. This would reduce the amount of duplication in the plugins config files.

      All the necessary values are now in the plugin build.xml file.

      This change will require that the plugins.xml file be retrieved from the build directory rather than the plugins directory when building the plugin documentation pages. We will therefore need a fall back to retrieve this file from the network if it is not currently available - this can be done with the locationmap

        Issue Links

          Activity

          Hide
          Ross Gardler added a comment -
          There is no description to this issue and it is a duplicate of the subsequent FOR-533 issue. I suspect it was a glitch in the migration process or something like that.
          Show
          Ross Gardler added a comment - There is no description to this issue and it is a duplicate of the subsequent FOR-533 issue. I suspect it was a glitch in the migration process or something like that.
          Hide
          Ross Gardler added a comment -
          Plugins.xml is currently unversioned. This results in the published plugins index being incorrect for older releases of Forrest. For more info see mail thread http://marc.theaimsgroup.com/?l=forrest-dev&m=114140648619147&w=2
          Show
          Ross Gardler added a comment - Plugins.xml is currently unversioned. This results in the published plugins index being incorrect for older releases of Forrest. For more info see mail thread http://marc.theaimsgroup.com/?l=forrest-dev&m=114140648619147&w=2
          Hide
          David Crossley added a comment -
          Some more discussion is now here:
           Re: Fixing FOR-533
           http://marc.theaimsgroup.com/?t=115625031300002
           
          Show
          David Crossley added a comment - Some more discussion is now here:  Re: Fixing FOR-533   http://marc.theaimsgroup.com/?t=115625031300002  
          Hide
          Ross Gardler added a comment -
          There is a problem with this approach (from the user mailing list):


          >> when i type "forrest available-plugins" i can see the required version
          >> for a plugin.
          >> i'm running 0.7 version and there almost all plugins required 0.8
          >> version. is taht really true?
          >
          >
          > This appears to be a problem with the generation of the plugins index.
          > It appears the 0.7 plugins index is showing the plugins for 0.8. We need
          > to make it so that the index only includes plugin version up to the
          > version number for the index being generated. That is, there should be
          > no 0.8 versions appearing on the 0.7 index page.
          >
          > It appears that we missed this when creating the versioned pages.

          I'm rushing again...

          The above described problem is not the one I am describing, although they are related. The index page on the website suffers the same problem, i.e. 0.8 plugins appearing on the 0.7 index.

          It looks like we need to keep a versioned copy of plugins.xml - attaching these comments the relevant JIRA issue.
          Show
          Ross Gardler added a comment - There is a problem with this approach (from the user mailing list): >> when i type "forrest available-plugins" i can see the required version >> for a plugin. >> i'm running 0.7 version and there almost all plugins required 0.8 >> version. is taht really true? > > > This appears to be a problem with the generation of the plugins index. > It appears the 0.7 plugins index is showing the plugins for 0.8. We need > to make it so that the index only includes plugin version up to the > version number for the index being generated. That is, there should be > no 0.8 versions appearing on the 0.7 index page. > > It appears that we missed this when creating the versioned pages. I'm rushing again... The above described problem is not the one I am describing, although they are related. The index page on the website suffers the same problem, i.e. 0.8 plugins appearing on the 0.7 index. It looks like we need to keep a versioned copy of plugins.xml - attaching these comments the relevant JIRA issue.
          Hide
          David Crossley added a comment -
          Ross explained some of what needs to happen:
          See http://marc.theaimsgroup.com/?l=forrest-dev&m=115628912024269
          Show
          David Crossley added a comment - Ross explained some of what needs to happen: See http://marc.theaimsgroup.com/?l=forrest-dev&m=115628912024269
          Hide
          Ross Gardler added a comment -
          I've done some of the work, the plugins.xml file is now generated from the build.xml file of plugins in the core and whiteboard plugin directories. This means the documentation page are dynamically generated.

          However, the plugin install system does not use this file. It can't because Forrest is not running while the plugins are being installed, although it could be since they are not actually mounted until the first request that uses them. I need to think and/or experiment around this a little. Longer term we will be using Ivy to resolve the plugins so I'm not sure if it is worth doing an interim hack.

          The other thing that is not currently supported is user defined plugin directories.
          Show
          Ross Gardler added a comment - I've done some of the work, the plugins.xml file is now generated from the build.xml file of plugins in the core and whiteboard plugin directories. This means the documentation page are dynamically generated. However, the plugin install system does not use this file. It can't because Forrest is not running while the plugins are being installed, although it could be since they are not actually mounted until the first request that uses them. I need to think and/or experiment around this a little. Longer term we will be using Ivy to resolve the plugins so I'm not sure if it is worth doing an interim hack. The other thing that is not currently supported is user defined plugin directories.
          Hide
          Ross Gardler added a comment -
          This work has been halted and reverted (by way of commenting out the plugins.xml match in plugins.xmap) in order to allows a 0.8 release without plugin source code.

          Moved the issue to 0.9 and reduced priority.
          Show
          Ross Gardler added a comment - This work has been halted and reverted (by way of commenting out the plugins.xml match in plugins.xmap) in order to allows a 0.8 release without plugin source code. Moved the issue to 0.9 and reduced priority.

            People

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

              Dates

              • Created:
                Updated:

                Development