Hi Murray, for plugins, most probably there'll be a signature change on WikiPlugin, from: String execute( WikiContext context, Map< String, String > params ) throws PluginException;
to: String execute( Context context, Map< String, String > params ) throws PluginException; With Context being a mostly drop-in interface of WikiContext. Likewise, PageFilter will probably face some similar changes. I'll look how to ease the transition / make current plugins / filters compatible but can't promise anything. WikiPageProvider will be moved to a new package (a reimport will be needed), but other than that will also be a similar case. I'd rather not make this backward compatible as this would mean having the same interface in two places.. In any case, I suspect the effort will be adapting to changes introduced by JSPWIKI-120: quite some methods from WikiEngine were moved to places where they made more sense. The more a current plugin interacts with JSPWiki, there are more chances that more things will have to be done to keep the plugin / filter / page provider up to date. Finally, just to be clear, the amount of changes that will be needed will be low: most of the changes involve reimporting classes or locating methods that were on a class and have been moved to another class, or using interfaces instead of classes that most of the time are drop-in replacements. I'll strive to ease or make current 3rd party extensions backward compatible as much as possible, but given we're walking towards a major release, now is the time to do this kind of changes. Don't know if anything / what else can be done :-? best regards, juan pablo On Thu, Mar 5, 2020 at 8:45 PM Murray Altheim <murra...@altheim.com> wrote: > Hi Juan Pablo, > > One of the things I have considered proposing I'll go ahead and > propose. I'm as seems typical lately rather overcommitted so I've > not been able to review what's going on with the new APIs but I > had the thought that it might be a good idea to actually support, > at least for some period of time, **two** plugin APIs, the old and > the new. This would enable existing wikis to continue to use older > plugins that may have not or may never get updated, whilst still > moving forward with newer versions of JSPWiki. > > The only difference between the old and new plugin APIs may > simply be its own package signature and the package signatures > of the respective dependencies (e.g., replacing WikiEngine with > its API, etc.). > > As the author of a lot of plugins, I'd still like to be able to upgrade to > the newer versions of JSPWiki for production sites, and upgrade my > plugins as time permits. There are likely a lot of private plugins > developed for personal or professional sites (that we never hear about) > whose developers are either too busy or otherwise unavailable for > updating them, and it'd be a shame to force those sites to either > abandon what might be essential plugins or never upgrade. > > Cheers, > > Murray > > ........................................................................... > Murray Altheim <murray18 at altheim dot com> = = === > http://www.altheim.com/murray/ === > === > = = === > In the evening > The rice leaves in the garden > Rustle in the autumn wind > That blows through my reed hut. > -- Minamoto no Tsunenobu > > > >
