Tags:
create new tag
, view all tags
ALERT! Note: We switched from CVS to SVN and moved all PluginsInSubversion. This topic here needs to be refactored and updated to account for the PluginsInSubversion. -- PeterThoeny - 02 Aug 2005

Restructure the Plugins Development

This topic started in UsingCVSForPluginsDevelopment. In time, as is wont to happen with discussions like this, the proprosed re -sructuring became the -structure, while a new batch of re -structuring talk began elsewhere like SharedCode. So now it's time to consolidate things a little, move the the's to UsingCVSForPluginsDevelopment, while keeping the re's here.


Open Issues

  • Recommended build tools/structure. KISS! [xxx where is this topic? xxx]
  • Recommended test tools/structure. KISS! [xxx ditto xxx]
  • Define how PluginsCoreTeam and Codev.CoreTeam work together on Plugin API enhancements.
  • Document overall dev process in ReadmeFirst, e.g. in a similar way to Codev.ReadmeFirst


I noticed the RCS *,v files (e.g.., in data/TWiki/*,v) aren't in CVS. Silly question: Does that mean future Plugin packages won't distribute these anymore? (Just an observation that since there's no history, the first Edit becomes 1.1.) actually some plugins have them and others don't. There are good arguments against distributing ,v files, and the opposing side a script which uses the ,v file to upgrade topics to a new twiki distribution.


Should there be guidelines on how Plugins are packaged? [XXXinsert right page hereXXX] On extraction, I find some drop their files into data/TWiki, others into data/Plugins (such as CalendarPlugin, ActionTrackerPlugin, and TWikiDrawPlugin), and at least one creates its own (i.e., XpTrackerPlugin puts files in data/Tracking).


Question: where should cvs related problems be reported? The support wiki, plugins wiki, or in sourceforge's tracker?

The reason I ask: I noticed twikiplugins/ChartPlugin/lib/TWiki/Plugins/ChartPlugin/ was empty.

Also, since it's prone to error, it might be prudent to tweak CVSROOT/cvswrappers to identify the common binary files (by file extension), instead of having to remember to mark files with -kb on checkins. (*.gif, *.png, *.jar, ...)


I am splitting up the WebForm into two forms: PackageForm for Add-On/Plugin/Skin packages (with many fields), and WebForm for all other types of topics (with only one TopicClassification field). This reduces the confusion where different form field values have been used in a ...Plugin and ...PluginDev topic.

IMPORTANT: In order to make this work we need to edit each Add-On/Plugin/Skin package and change the form from WebForm to PackageForm. Please help in making this happen. Edit the topic and [ Change ] the form. Take this also as an opportunity to check if the field values are correct; there are some new ones recently like CVSModificationPolicy.

As soon as the form of all package topics have been changed to the PackageForm I will change the WebForm and remove all fields but the TopicClassification.

-- PeterThoeny - 19 Apr 2003

Does this mean that we are now going to call the generic for Plugin/Skin/Addon a package?

Wouldn't TWikiExtension be a better name? Package seems a bit non-specific. It leaves me wondering whether it is would be TWikiCore that we are packaging or the "other stuff"?

Additionally, I think it would be a good idea to add the | Changes (Detailed) | to the Plugins menu option. If you use the standard WebChanges view then it appears that every topic in this web has changed, which although true by side-effect, the semantics are best reflected by the changes script. (Peter, while I think of it, how do I write a link to the changes script - is there a WikiWord that invokes it?)

-- MartinCleaver - 20 Apr 2003

  1. In the mean time I did some automation and used the rename feature of TWiki to selectively change the form of all Add-On/Plugin/Skin package topics to the PackageForm. Please check your topics, I might have missed some.
  2. Also, please note that topics with a WebForm (all dev, brainstorming, etc) topics still have the old fields. The obsolete form fields will get removed once you edit the topic.
  3. I think TWikiExtension is a good umbrella term for Add-Ons/Plugins/Skins. Listing them separately in the WebHome is a good way of presenting the big pool of extensions, therefore it makes sense to keep the TopicClassification.
  4. Good idea with the | Changes (Detailed) | links, is done now. There are too many topic changes in an automated mass-fix like this.
  5. Martin: The proper way to link to the changes script is this:
    [[%SCRIPTURL%/changes%SCRIPTSUFFIX%/%WEB%][Changes]]

-- PeterThoeny - 20 Apr 2003

(I've numbered your points so to address them directly)

  1. Are there any known reasons as to why the automated rename would miss any?
  2. It would be useful if there was a means of either flagging that an instance of a form is out of date with the template or to update it automatically. How else are people to know that they should edit the form to make the new field appear?
  3. Can you elaborate on "Listing them separately in the WebHome ..., therefore it makes sense to keep the TopicClassification"? I don't understand
  4. Thanks
  5. How about renaming the WebChanges to WebChangesDetailed and create a WebChanges page that returns the result of the changes script?

-- MartinCleaver - 20 Apr 2003


New Directions

Thinking about a precursor to CommonFrontEndCgiScript to handle plugin bin requests (and avoid PluginBinNameClashes). This action script would sit in TWiki's bin and would provide a syntax such as:

http://twiki.org/cgi-bin/action/WebPath1.WebPath2/TopicName/QuickSavePlugin/quicksave?param1=value1&param2=value2

I believe MegaTWiki 's mega cgi-script could form the basis of this.


It sounds like the whole plugin management is an attempt to duplicate the http://SourceForge.net functionality. Codev.TWikiForge


Appropriate here to mention TWikiWebDavServer here? WebDAV seems to be a solid direction for Plugin architecture/development in general. Please correct me if I'm wrong. see WebDAVAddOn


Issues put to rest

Select a TWiki Plugins Project Leader. Nobody stepped forward for the role. cvs-plugins development went ahead anyway and has progressed for about two years. There is no obvious reason at this time (early 2004) we can't continue this way.

PluginsCoreTeam: if you have cvs write access, you are a plugins core team member. The group is probably misnamed, as it in no way resembles the structure and workflow of Codev.CoreTeam on the main TWiki.

Issues not yet dealt with

A possible solution to keeping a single repository while maintaining inner-outer code areas might be to write some perl LWP tools that committed/map "code files" to Topics and subtopics, simply committing the whole file into some tags, say:

%CODE SECTION BEGIN% 
%CODE SECTION END%
Or some subtopic render mechanism. You would let the TWiki backend deal with the versioning. Probably not hard to do. You could probably work a whole build system into TWiki that way.

  • We probably should augment the webform for the Plugins web, to include an item describing where it is versioned. Either on SourceForge, etc.

  • We do need to come up with a build model. Ie. Something that "builds" or in essence bundles all the necessary files into a zip. MakeStrategy

  • Im not sure how to do it (perhaps symlinks on unix), but we need to describe a working model for having both twiki and twikiplugins checked out and reasonably easy to work on both. Automation would be nice, but Ive got a gut feel the best we will be able to muster is documentation.
    • I do this by running a TWiki off a checkout area (cvs checkout of twiki). I then have a parallel checkout of TWikiPlugins. Where plugins have build files with an install target, I use that to install to the twiki checkout area. Where they don't, I just use cp. Works pretty well. Ideally every plugin should have a buildfile with install and uninstall targets - see MakeStrategy

  • We also might want to separate skins from other plugins in the directory tree. It seems a reasonable separation to me, but perhaps I am being overly anal retentive...
    • I favour separating skins, plugins and addons. I'm even more anally retentive than you!
    • I don't. If you do that, how do you handle a Skin like GnuSkin, that also has a plugin? Doesn't make sense; keep it simple. -- CC

  • Build model. I've been using Ant because I use it with Java and find it really easy to use. For an example of an Ant build file, see the attachment. Of course, it might make more sense to use perlmake.... but Ant does have some 'social' advantages (like encouraging use of a test-infected development methodology). See MakeStrategy

  • can't we get rid of the tar.gz or zip file altogether by using a script that gets that plugin from CVS using cvs tags?
    • Yes, we could, but we'd have to have a script running on sourceforge, which would be a pain. -- CC
    • i think that the script you mention should build the .zip file and attach it to the appropriate plugins topic (this happens during the AutomatedBuild stage); an installer could use something along the lines of the AutomatedPluginsDownload script -- WillNorris - 24 Sep 2004
    • KISS: Better to keep the zip on the Plugin topic. Not everyone is connected to the Internet (some companies in aerospace etc)

Collaboration / Group Editing

The CVSModificationPolicy could be extended by adding a CVSTrustedEditors flag, e.g:

CVSTrustedEditors AndreaSterbini, CrawfordCurrie, PeterThoeny, MartinCleaver, SvenDowideit, MattWilkie, WillNorris

Note: this would not be a security measure, any twikiplugins developer is still able to change anything in the entire repository. It would just be a way for the author or primary maintainer to say "I feel comfortable with any of these people changing my code without asking."

Contributors: AndreaSterbini, PeterThoeny, NicholasLee, DennisDaniels, SteveRoe, CrawfordCurrie, JohnCavanaugh, RichardDonkin, MartinCleaver, GrantBow, SvenDowideit, MattWilkie, AndreaBacchetta, AnthonPang, PeterKlausner, WillNorris,


Discussions

I've initiated some heavy handed refactoring of this topic. It might be a good idea to look it over and make sure it's all kosher. smile

There is still some cleanup, like links to relevant discussions elsewhere; if you know, please fix. Also I wasn't sure how to best convert the largish section of dialogue between Peter and Martin into document mode. Feel free to take a crack at it. I'm all tuckered out!

-- MattWilkie - 13,15 Apr, 04 May 2004

Edit | Attach | Watch | Print version | History: r42 < r41 < r40 < r39 < r38 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r42 - 2005-08-02 - PeterThoeny
 
  • 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.