On Fri, Apr 13, 2012 at 5:27 PM, Jean-Vincent Drean <[email protected]> wrote: > On Wed, Apr 11, 2012 at 8:52 PM, Paul Libbrecht <[email protected]> wrote: >> >> hello devs, >> >> having moved Curriki to the 3.5 core, we noticed our activity stream was >> having empty getDisplayBody... looking more closely revealed that the >> objects were all of type ActivityEvent while a family of sub-classes was >> available in the CurrikiActivityStream: the method >> ActivityStreamPluginApi.wrapEvents was made private hence its subclass was >> ignored! >> >> This appears to have been made at >> https://github.com/xwiki/xwiki-platform/commit/1837196f0f6434603c4c24a13b7c1e2330750de8 >> as part of a "code cleanup". Jean-Vincent, or someone else, could you >> explain the rationale behind it? I am sure this was checked for "others >> usages" but Curriki was not considered as part of that. >> > > I had forgotten I did this refactoring/cleanup. > It seems I wrongly considered those APIs as internal, this is indeed a > regression. I'll fix it ASAP.
Done: http://jira.xwiki.org/browse/XWIKI-7731 > >> Having somewhat fixed this on my side by bringing more methods to the >> subclass (for the display of older events), I come to realize that newer >> events are also not of the right type so I'll have to hunt more for >> "compromised subclassing"... >> >> This is rather an API breakage to my taste. >> Has there been a policy about this? >> Could we set-up one? >> I wonder if such a search engine exists that would have indicated that such >> a breakage would have been avoided. >> > > I think clirr is doing this job now. > > -- > Jean-Vincent Drean, > XWiki. -- Jean-Vincent Drean, XWiki. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
