Item9774: Dependency issues with Foswiki 1.1

Several issues noted

• Installation of EditRowPlugin down-revs JSCalendarContrib

  ====== MISSING ======
  Foswiki::Contrib::JSCalendarContrib version >= 14754 required
   -- installed version is 31 Jul 2010
   -- Description: Javascript calendar module

• Other default extensions listed by FindMoreExtensions are shown as needing upgrade to an older release.

  Extension	Recent	Installed
  FamFamFamContrib	2009-01-21	1.2
  HistoryPlugin	08 Dec 2008: (V1.4)	1.6
  SlideShowPlugin	16 Dec 2008	2.1.1
  TWikiCompatibilityPlugin	2010-01-11	1.1.1

Also some extensions generate dependency errors in the Apache log:

Warning: EditRowPlugin has badly formatted RELEASE: $Date: 2011/04/16 22:26:13 $
Warning: EditRowPlugin has badly formatted svn id in DEPENDENCIES: 24 Feb 2009
Warning: FamilyTreePlugin has badly formatted RELEASE: TWiki-4
Warning: FamilyTreePlugin has badly formatted svn id in DEPENDENCIES: 09 Jan 2009

-- GeorgeClark - 30 Sep 2010

These messages should NEVER be shown to end users. They are developer type messages.

We have to be careful with all the checking we have introduced.

If the RELEASE or DEPENDENCIES do not match format or are invalid, no upgrading or downgrading should happen and the warning message should clearly say that the extension has been installed anyway and that the admin should manually check the dependencies.

SlideShowPlugin has the wrong Release string in the Extensions web. This gets corrected next time we release the extension which is in a few days.

-- KennethLavrsen - 01 Oct 2010

Actually the SlideShowPlugin was revised in 1.0.10 but noone uploaded it.

I had not noticed this. Correcting now. But it will only live for 1-2 days

-- KennethLavrsen - 01 Oct 2010

The messages are not shown to the user. They are generated in the apache log. I don't think there is anything here that should block 1.1, as long as Extensions directory is updated so that configure installs the correct versions.

-- GeorgeClark - 02 Oct 2010

If we do not downgrade plugins and only warn in Apache log then it is not urgent at all.

-- KennethLavrsen - 03 Oct 2010

From what I can tell, the issue comes when the Extension does not sync the Version: and Release" fields in the Extension topic with the $VERSION and $RELEASE fields in the Extension module. Dependency.pm uses the Extension module variables to determine what is installed. configure FindMoreExtensions FastReport to get the Topic Release and Version fields, and asks Dependency.pm to compare them to the Extension.pm fields.

If the Extension Topic and the Module are inconsistent, I don't see how we can reliably fix this.

-- GeorgeClark - 04 Oct 2010

From what I can tell, the issue comes when the Extension does not sync the Version: and Release" fields in the Extension topic with the $VERSION and $RELEASE fields in the Extension module. Dependency.pm uses the Extension module variables to determine what is installed. configure FindMoreExtensions FastReport to get the Topic Release and Version fields, and asks Dependency.pm to compare them to the Extension.pm fields.

If the Extension Topic and the Module are inconsistent, I don't see how we can reliably fix this.

I've been doing some analysis of the svn directories.

All extensions need to have an extension.pm module

Without this, Foswiki cannot determine what is installed. Our own BuildContrib is an example of this.

Extension.txt topic must use %$RELEASE and %$VERSION

Manually maintained strings are not reliably compared by Dependency.pm

build.pl upload needs to block release if these are violated

We really need to keep the Extensions web "clean" if we expect Dependency.pm and the extension installer to be reliable.

-- GeorgeClark - 04 Oct 2010

It appears as though the refactoring done for the new Configure UI dropped the code that scrapes the Version and Release from the extension topic. So configure now exclusively uses the Extension module to determine the installed version. This is probably good most of the time, but there are some extensions, like BuildContrib, that don't install a module. So they are always missing from Configure.

There are probably only a handful of extensions where this situation exists. So probably better to add the dummy extension module than to add in the text parsing. This is the list of "missing modules" extracted from a svn checkout.

 BugsContrib/lib/Foswiki/Contrib/BugsContrib.pm 
 BuildContrib/lib/Foswiki/Contrib/BuildContrib.pm
 CacheAddOn/lib/TWiki/Contrib/CacheAddOn.pm 
 CacheChooserAddOn/lib/TWiki/Contrib/CacheChooserAddOn.pm 
 CompareRevisionsAddOn/lib/Foswiki/Contrib/CompareRevisionsAddOn.pm 
 ConfluenceToFoswikiContrib/lib/Foswiki/Contrib/ConfluenceToFoswikiContrib.pm 
 FormsAddOn/lib/TWiki/Contrib/FormsAddOn.pm 
 GenPDFLatexAddOn/lib/Foswiki/Contrib/GenPDFLatexAddOn.pm 
 MailPageAddOn/lib/TWiki/Contrib/MailPageAddOn.pm 
 MailToTWikiAddOn/lib/TWiki/Contrib/MailToTWikiAddOn.pm 
 MakeCtrlTopicsListAddOn/lib/TWiki/Contrib/MakeCtrlTopicsListAddOn.pm 
 NamespaceManagerAddOn/lib/TWiki/Contrib/NamespaceManagerAddOn.pm 
 NavBarAddOn/lib/TWiki/Contrib/NavBarAddOn.pm 
 NestedFormsPlugin/lib/Foswiki/Plugins/NestedFormsPlugin.pm 
 NotifyOnChildModificationTopic/lib/TWiki/Unknown/NotifyOnChildModificationTopic.pm 
 OpenSourceProjectInAWebContrib/lib/Foswiki/Contrib/OpenSourceProjectInAWebContrib.pm 
 PollPluginSvenHess/lib/Foswiki/Unknown/PollPluginSvenHess.pm 
 SpellCheckAddOn/lib/TWiki/Contrib/SpellCheckAddOn.pm 
 TWikiShellContrib/lib/TWiki/Contrib/TWikiShellContrib.pm 
 UploadToTWikiAddOn/lib/TWiki/Contrib/UploadToTWikiAddOn.pm 
 UserHomePageAddOn/lib/TWiki/Contrib/UserHomePageAddOn.pm 
 YetAnotherXpTrackerPlugin/lib/TWiki/Plugins/YetAnotherXpTrackerPlugin.pm 

I'm still working on code to pull out and compare the module versions with the Text file versions to find inconsistencies.

-- GeorgeClark - 04 Oct 2010

Another issue - a number of extensions have copied the wrong example build.pl which breaks the lookup of the RELEASE / VERSION identifiers. Ex.

 return bless( $class->SUPER::new( "TimelinePlugin", "Build" ), $class );

The operand "Build" causes BuildContrib to try to find Plugins/Build.pm to recover the identifiers.

-- GeorgeClark - 04 Oct 2010

Note that pieces of this were picked up in 1.1.1 and 1.1.2. but it never got into the release notes. Will document in 1.1.3.

-- GeorgeClark - 04 Mar 2011

Commenting is disabled while not logged in