Hi, I'm almost done with JSPWIKI-120 (aka big refactor on WikiEngine) and, after it, I'd like to retake JSPWIKI-303 (JSPWiki public api) before next release.
As of now, I've came up with the following classes/interfaces for the public API, that should be enough for most of the typical JSPWiki extensions out there. We could add further classes/packages later on, but I think it's ok for a first approach: * o.a.w.api.core: core API interfaces ** Engine and Context, extracted from WikiEngine and WikiContext ** Page and Attachment, extracted from WikiPage and Attachment ** Acl and AclEntry, promoted from the o.a.w.auth.acl package (as they are used by Page, Attachment and Context) ** Command, promoted from the o.a.w.ui package (as WikiContext is implementing Command) ** o.a.w.Release promoted to this package? * o.a.w.api.exceptions: JSPWiki custom exceptions * o.a.w.api.filters: Filters API (modified to require Context instead of WikiContext) * o.a.w.api.plugin: Plugins API (modified to require Context instead of WikiContext) * o.a.w.api.providers: Page providers API, it would contain WikiProvider and WikiAttachmentProvider from org.apache.wiki.providers Some of the classes from which the API is extracted also rely on classes on the o.a.w.event package, so there's a slight chance that the o.a.w.event package will become a dependency of the public API. Have to take a better look at it. As of now, the o.a.w.event package can be extracted to its own independent module, so it shouldn't be a big deal. As of this quarter release, I think right now it makes sense to skip it: current changes related to JSPWIKI-120 have a good probability of breaking existing 3rd party plugins/filters (most likely if they interact with the WikiEngine), and that is likely to happen again when introducing the public API. Also, this quarter work has been mainly around JSPWIKI-120, so releasing now wouldn't unlock new features or bugfixes, but rather just have a release which may break current 3rd party integrations. This was bound to happen sometime, but in order to minimize the chances of breaking again the JSPWiki API I think it's better to skip this station. Thoughts? Am I missing something, should the API include more things, or is it too wide,..? best regards, juan pablo
