Public API compatibility with current plugins, filters and page/attachment providers

[Juan Pablo Santos Rodríguez <ju...@gmail.com>]

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