On Fri, Apr 13, 2012 at 5:27 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
On Wed, Apr 11, 2012 at 8:52 PM, Paul Libbrecht
<paul(a)hoplahup.net> 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/1837196f0f6434603c4c24a13b7c… 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.