Hi, part of the appeal of JSPWiki is for me that I can reach deep into the wiki engine from plugins. JSPWiki is for hackers, BigCorps use Confluence. And as hacker I want control, I need to look into the Wiki core and use what it offers, or work around its limitations. So I'd rather prefer no API changes, I'd like the Wiki to stay binary and API compatible. There are enough plugins out there that didn't make the move to org.apache.wiki. As I understand this public API would bring no advantage in functionality or user experience, only an aesthetic pleasure to the software engineer's eye. A big advantage of the old Java and EE eco system is that it mostly kept compatible. So should JSPWiki.
Greetings, Juergen Am Mo., 24. Feb. 2020 um 22:48 Uhr schrieb Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com>: > > 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
