create new tag
, view all tags
This page is converging on a description of the methods to be used for building and installing plugins.

Build Strategy

It would be really good if there were a single strategy for building plugins and their associated data that was really easy to use, and worked on all possible development platforms. Some ideas:
  1. The make process should be data-driven as far as possible. Shipping a Makefile with every plugin is viable.
    • Importantly, there should only be one place where all the files are listed.
    • Other lists can be derived from that master list if they are required.
  2. The make process has to support four targets; build, test, install and release.
    • build performs a syntax check on perl, and invokes the build process for any language modules such as Java code. It could do this by looking for an Ant build file in the plugin directory lib/TWiki/Plugins/MyPlugin/build.xml (Ant is pretty much a standard for building Java)
    • test runs unit tests. This should be as simple as invoking a script in a subdirectory of the plugin directory. A good name would be lib/TWiki/Plugins/MyPlugin/test/testrunner.pl, as this is consistent with Test::Unit (or /t/ if we use MakeMaker)
    • install installs the plugin in a local twiki defined by an environment variable $TWIKI_HOME. This is primarily for manual testing.
    • release builds the zip file for releasing. Conditionally it could upload the release if an internet connection is available, but this should not be the default behaviour. If it does do the upload, it should automatically update the plugin topic as well as uploading the zip.
  3. The tools must be lightweight. If a plugin developer has to spend 10 minutes downloading Perl packages required for building, they'll find another way. An option would be to follow MartinCleaver's approach in PluginCvsToolsAddOn and create a downloadable package of tools (or, preferred, "tool").
  4. The scripts used to enable the make strategy should be in shared/tools

Install strategy

That was the easy bit. Much harder is the handling of dependencies for the install. Dependencies are of four possible types:
  1. Static dependencies on CPAN modules
  2. Static dependencies on shared code
  3. Dynamic dependencies on other plugins
  4. Patches for core TWiki code
Whetever we do has to be able to handle all of these.
  1. Dependencies should be expressed in the same way as the source files for the build i.e. in a makefile of MANIFEST.
  2. CPAN could be used to handle dependencies (note: MS has presented some cogent arguments against using CPAN for shipping the core on TWikiIRC. Certainly there may be a security problem associated with depending on a potential fire risk as CPAN)
  3. Plugins could ship with a standard install script, called Install_MyPlugin.pl, that has to be invoked after the package is unzipped. This script could also double as an uninstall ( perl Install_MyPlugin.pl uninstall ).
  4. The install script could patch testenv to add required CPAN modules?
    • related to TestenvInterface; I prefer a perl module/namespace that can be included/invoked by testenv
  5. Or it could check the perl installation itself (big assumption that apache user is using same perl version here)?
  6. It could certainly detect shared plugins code dependencies, and download and install missing shared code modules
  7. Or it could simply report missing shared code modules?
  8. And missing plugins?
  9. The installed needs to know about version dependencies, of course, and know how to resolve them. I would favour the following approach:
    1. Plugins express the code version they are tested against
    2. If a more recent shared code version is installed, it is automatically assumed to be compatible, though a warning should be issued.
    3. If an older version is installed, the installer should update the shared version to the required version. This may break other installed plugins
    4. Optionally, if the installer has to upgrade a version, it might run the install script for all previously installed plugins with a check_dependencies parameter.
  10. Of course, the install script can't assume an internet connection when checking/resolving dependencies, but it would be nice if it could leverage one if it was there.

Some other notes

  1. It would really help if plugins only had one version number; at the moment the version number is duplicated in the code and the plugins topic. Perhaps the make process could rationalise this.
  2. The make test process might optionally detect any abuses of the APIs, in the way the conformance check script does.
  3. The standard install script could optionally invoke an install script in the plugin directory if there is extra install steps the plugin author wants to perform.
  4. I can't think of any good reason why skins shouldn't follow exactly the same make andinstall process.
  5. The install script could offer to send mail to record the fact that the plugin was installed. Of course, the installer can opt to say "no way, Jose!".

I wanted to investigate the feasibility of writing a standard-ish makefile in perl for plugins that would do what we asked of it. My attempt is attached - please comment, change, make better. Most of it is standard stuff, and could be shipped as a module with the TWiki core, simplifying plugins build scripts even further.

-- CrawfordCurrie - 17 Apr 2004

Crawford, why would a makefile not be able to just copy files into the correct place. Any software package (TWiki or not) has such files (Readme files, help files, etc.). What am I missing?

-- ThomasWeigert - 18 Apr 2004

In TWikiIRC a small conflagaration ensued this approach. The fuel was confusion about intention and the validity of this approach. It looks like the results might be healthy new growth: http://www.owiki.org/twiki/bin/view/Openwiki/MakeStrategy

-- MattWilkie - 19 Apr 2004

SharedCode now contains the evolution of my script as a Perl build module. It works really well, and is very easy to use. Just install to be solved, now. Some notes about the builder:

  1. It uses perl, not make
  2. It is highly twiki-specific
  3. It is almost a direct translation of my original ANT files
  4. It handles build, test, pod, release, and upload
  5. It does not handle install, other than local install to the developers test wiki

-- CrawfordCurrie - 12 May 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt build.pl.txt r1 manage 4.0 K 2004-04-17 - 19:41 CrawfordCurrie WebDAV perl build/uninstall file
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2004-05-12 - 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.