Hi, last push includes public API compatibility with current plugins, filters and page/attachment providers.
Custom plugin and filters should continue to work without needing to do anything, although it would be nice if they upgrade to use the new API. Log warnings are to be expected when not using the public API. Custom page / attachment providers should include some changes in the jspwiki[-custom].properties file: - For custom page providers, the jspwiki.pageProvider property should be set to WikiPageAdapterProvider and then the jspwiki.pageProvider.adapter.impl property should be added, with its value being the actual custom page provider - For custom attachment providers, the jspwiki. attachmentProvider property should be set to WikiAttachmentAdapterProvider and then the jspwiki.attachmentProvider.adapter.impl property should be added, with its value being the actual custom attachment provider There are a couple of new maven modules to ensure through unit tests this backward compatibility. Caveat: if a plugin/filter/etc. hits a method moved due to refactoring on JSPWIKI-120, then the plugin/filter/etc will be loaded but, the part using those methods won't. Given that these methods were mainly internal and we're in the middle of a transition to a minor release, this should not be unexpected. Caveat aside, In order to allow as much extensions as possible to continue working as usual, I'd like to ask custom filter/plugin/providers authors out here to test them against latest master and see what are you missing, or what do you need for the extension to continue working. There are already some tradeoffs to accomodate current extensions (i.e. see o.a.w.search.SearchMatcher class) into the public API, so adding back a few methods here and there should not be a big problem.. cheers, juan pablo
