create new tag
, view all tags
I submitted a couple of Plugins yesterday, and I have a couple more to go. The process has raised a number of points which I've had to resolve using best-guess judgement.

  1. There's no standards that I could find for plugins having their own support libraries. I have elected to place these in lib/TWiki/Plugins/<plugin name>/*.pm. (See TocPlugin for an example)
    • PeterThoeny - That is the way to do. Will be documented.
  2. The old 'standard' for shipping Java jar files in pub feels wrong; for example, for TWikiDraw I have placed the jar file in pub/Plugins/TWikiDrawPlugin/twikidraw.jar. Perhaps it should be in lib/TWiki/Plugins/<plugin name>/<jar name>.jar ? That keeps all the plugin data together.
    • PeterThoeny - We cannot do that because the lib dir is outside the htdoc tree for most installations. The best place forjar files, images and such are attachments to the Plugin topic itself.
    • CrawfordCurrie - OK, let's standardise on pub/Plugins/<plugin name>/<jar name>.jar (N.B. Can't standardise jar name - There may be multiple jars!)
  3. There's no standards for shipping tests. All my code (perl and Java) has unit and module tests; I have shipped these in lib/TWiki/Plugins/<plugin name>/test - Arguably we should keep all these in the top level 'tools' directory but that feels wrong to me.
    • PeterThoeny - This sounds sensible to me. At a later point we can call those Plugin test scripts from a master test script.
    • CrawfordCurrie - I've shipped the perl tests in lib/TWiki/Plugins/<plugin name>/test.zip
  4. There's no standard for shipping sources. I have elected to standardise on shipping in lib/TWiki/Plugins/<plugin name>/src
    • PeterThoeny - This is N/A for Perl. For Java source I suggest to pack it in a ZIP or tar file and place it in lib/TWiki/Plugins/<plugin name>/.
  5. GenHTML is not actually a plugin, it's a new bin script; despite this I've used the above standards to ship the module and it's tests.
    • PeterThoeny - We will have ...Plugin, ...Addon and ...Skin topics in the Plugins web. Please wait for a while until we added those sections. So a good name for your add-on is GenHtmlAddon.
  6. There's no standards for build scripts. I have used Ant http://www.jakarta.org as it is pretty standard in the Java world.
  7. There's no standards for writing tests. I have used JUnit for all Java tests.
    • PeterThoeny - Needs to be investigated if we should standardize this.
    • CrawfordCurrie - we really should standardise on JUnit for java. I don't have an opinion on perl, unless there's a PerlUnit, in which case I'd go for that.
  8. I guess most of the existing plugins have all the help they needed embedded into the Plugin topic. At least one of my plugins requires a lot more help than that. Currently I'm shipping a data/Plugins/<plugin name>Plugin.txt which is different to the one generated from the form in this web; it's much more of a help page for the plugin. I'd appreciate some kind of standard for shipping these kinds of help pages (how about data/Plugins/<plugin name>Help.txt ?)
    • PeterThoeny - The ...Plugin topic in the distibution and here in the Plugins web should be identical (except for the WebForm table). It is possible to ship additional topics if needed, the InterwikiPlugin does that.
    • CrawfordCurrie - This is a pain. To keep them identical is too much work.
      • PeterThoeny - I see it the other way, it makes it simpler. I.e. I have the master SpreadSheetPlugin topic in the TWiki web on my Alpha installation. After I make changes to the topic in the Alpha installation and I run a small script that packages the plugin, I copy the topic content over to the Plugins.SpreadSheetPlugin topic here, and attach the plugin zip file.
      • CrawfordCurrie - I guess it's up to your development environment. I do development on a machine isolated from the internet (no Linux support for my modem at home, and my works portable is only plugged in occasionally). I use Ant release scripts that package the zip. Currently they also have to separately generate the Plugin page. When I get re-connected (usually every 2-3 days) I can easily upload the zip, but I have to manually edit the Plugin topic on TWiki.org and paste in any changes to the text. If, on the other hand, I do all my edits on TWiki.org I have the same problem in reverse, getting the changed text into the release package, with all the associated risks involved in all these nasty manual steps. I appreciate that my environment is probably an extreme, but it does highlight how requiring maintainance of two copies in synch introduces risk for the developer.
  9. I'm not shipping ,v files for any Plugin .txt files. Should I be? I don't really see the point as these topics should be read-only.
    • PeterThoeny - This is arguable. The reason to ship the ,v files is to be able to go back to the original topic version if needed.
    • CrawfordCurrie - If someone changes the Plugin locally, yes. I really dislike this business of shipping the Plugin topic in the package. I feel it would be far better to use the Plugin topic as a simple synopsis and download page, and only ship detailed help. The Plugin topic should only exist in one place - on TWiki.org
      • PeterThoeny - Again, I think it is better to have the Plugin topic content identical. It also should contains the Plugin configurations.

Hope all this is OK; it would be nice to standardise all this stuff before someone else runs into the same problems. If anyone doesn't like what I've done I'm quite happy to change.

-- CrawfordCurrie - 17 Sep 2001

Very good feedback. We are still refining the Plugins. See comment above. Please add more comment to this topic here.

-- PeterThoeny - 21 Sep 2001

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2001-09-25 - CrawfordCurrie
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.