Ticket #31 (closed feature: wontfix)
Opened 2010-02-19T15:40:26-06:00
Last modified 2014-06-23T14:02:04-05:00
Central plugins repository
Reported by: | curtis | Owned by: | curtis |
---|---|---|---|
Priority: | major | Milestone: | imagej-2.0.0 |
Component: | Community | Version: | |
Severity: | non-issue | Keywords: | |
Cc: | Blocked By: | #1468 | |
Blocking: |
Description
There are several large collections of plugins online:
- The main ImageJ site's list, including links to many external sites
- The ImageJ Documentation Wiki's list
- The ImageJ Plugins project
- Fiji comes with many plugins, and the ability to automatically update them to the latest versions available from the Fiji repository
We would like to create a central list of plugins here at ImageJDev.org. Since the site uses Drupal, it can allow user contributions similar to the ImageJ Documentation Wiki, but the process can be more structured. Drupal allows custom content types, and the ability to create views of the data as tables and lists. It also allows file attachments. This approach would eliminate the need to manually update index pages and other such bookkeeping.
Ultimately we would also like to have an update checker that does plugin updates based on the latest versions available here.
Change History
comment:1 Changed 2010-02-19T15:45:42-06:00 by curtis
comment:4 Changed 2014-06-23T14:02:04-05:00 by curtis
- Status changed from new to closed
- Resolution set to wontfix
The current thinking is to standardize everything in the ImageJ Wiki (which is also the Fiji Wiki), which will be the imagej.net site. No more Drupal. See https://github.com/imagej/imagej/issues/71.
What we cannot do is magically suck in plugins from other sources such as the ImageJ Documentation Wiki. (Well, in that particular case, maybe we can work with Tudor to get that wiki merged with the ImageJ Wiki, but it is certainly not urgent.) Really it is up to us to provide the best possible central mechanism for ImageJ plugins -- and we have a very good start on that with the personal update sites -- and up to individual authors to take advantage of that mechanism.
We have created a preliminary "ImageJ plugin" content type on the site, and created one page to demonstrate the idea:
We still need to create tabular views to show an indexed list of plugins.
To migrate plugins from the main site en masse, it would be straightforward to harvest and parse all the HTML, generate a spreadsheet of information, proof-read it for errors, and then generate SQL insert statements to populate the information.