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. > 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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
