Hi, I didn't want to start a branch because my intention was to push the API into trunk gradually. Also, as the API is being checked in, the build is still backwards compatible so it's possible to develop plugins, filters, etc. totally ignoring the API.
In 2.10 we should get rid off the @Deprecated API-related classes/methods, but until then, the API should be transparent, i.e.: I left some tests and plugins in $svn/tests against org.apache.wiki.plugins.WikiPlugin instead of org.apache.wiki.api.WikiPlugin, just to ensure that the @Deprecated classes/methods are still functional. Also, the UPGRADING document gives a quick overview of the API and associated changes. With all that in mind, I think that's safe enough to push the API in trunk. WDYT Regarding why the API, and on what is based, my intention is to modularize the source, that meaning no more red squares at [#1], so we're able to talk about several individual modules like jspwiki-api, jspwiki-plugins, jspwiki-ctags. As a consequence of that, the API emerges by itself, which made me look at the 3.0 API, JSPWIKI-303 and http://www.jspwiki.org/wiki/JSPWiki3APIDesignProposal br, juan pablo p.d.: as a side note, I was planning on targetting at filters for the nexts commits regarding the API.. [#1]: https://analysis.apache.org/drilldown/measures/110730?metric=package_cycles On Sun, Dec 16, 2012 at 11:56 AM, Florian Holeczek <[email protected]>wrote: > Oops... Just saw that my answer came too late. > > > Am 16.12.2012 12:53, schrieb Florian Holeczek: > > True... I'm thinking of the API to be a very good thing, but I haven't >> got enough time to follow this at the moment. Having the possibility of >> looking at the progress on a separate branch would surely lower the hurdles. >> >> @Juan Pablo: Did you base your work on Janne's previous work, or is it >> something completely new? >> >> Regards >> Florian >> >> >> Am 14.12.2012 20:31, schrieb Siegfried Goeschl: >> >>> Hi Juan Pablo, >>> >>> maybe a SVN feature branch would be a good idea ... >>> >>> Cheers, >>> >>> Siegfried Goeschl >>> >>
