Hi Thomas and all,
I’ve just done the analysis of the xwiki-commons-job TPC loss displayed on http://maven.xwiki.org/site/clover/20190108/XWikiReport-20190101-2330-20190… (and it’s still the case today on http://maven.xwiki.org/site/clover/20190202/XWikiReport-20190101-2330-20190…).
xwiki-commons-job 84.3812 84.2416 -0.1395 -0.0002
There were only 2 classes that have had changes in TPC:
* DefaultJobProgress - lowered TPC
* AbstractRequest - increased TPC
But there’s more lowering than increasing globally which is why it’s in red.
Specifically the lowering happened in 2 places:
* http://maven.xwiki.org/site/clover/20190108/clover-commons+rendering+platfo… vs http://maven.xwiki.org/site/clover/20190101/clover-commons+rendering+platfo…
* http://maven.xwiki.org/site/clover/20190108/clover-commons+rendering+platfo… vs http://maven.xwiki.org/site/clover/20190101/clover-commons+rendering+platfo…
Note that no source code changed in the job module.
Conclusions:
* It was hard to track and I need to improve the report to show a package level difference too and not just modules, at least for modules going down. Actually, even better would be a class level difference too for modules going down.
* In this case, I believe we had some bugs in XWiki somewhere that led to hitting the "Could not find any matching step for source [{}]. Ignoring EndStepProgress.” error. Could someone confirm that, it rings a bell to me?
* It also shows there’s no module level tests (ie unit tests) that go on in this IF and it would be good to add one to prove that we get a log when we have an end without a start.
It’s interesting because this is a use case where our global TPC went down because we fixed a bug (and thus indirectly we enter into less code). It mostly highlights that we don’t tests this case and we should.
Thanks
-Vincent
Hi devs,
I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
rename job (from refactoring module) to update the existing objects when a
class is renamed *if the "Update links" options is checked*.
Of course, we could add a new option (e.g. "Update objects") but:
* it complicates the rename UI (too many options)
* I think most of the users understand the current "Update links" option as
"update the places where this page is *used*". I don't think it makes sense
to have separate options (at least at the UI level) for things like "Update
macro calls" or "Update image includes".
* I don't see why you would want to update the back-links but not the
objects (or the other way around).
If we agree on using a single option ("Update links") then the next
questions are:
* Is there a better name? I think "Update links" is a good name for simple
users so I would keep it. Another option is "Update references" but it has
a special meaning for XWiki developers.
* Should we update the hint for the "Update links" option? I think we
should, but only for advanced users, since they should be aware of the
implications of renaming a class. Simple users are not aware of the
existence of objects, most probably, so I wouldn't complicate their lives.
The final question is whether we should keep the rename job question about
classes. I think we should. The reason we added it is because renaming a
class is currently dangerous. Updating the objects makes it a bit less
dangerous because the data is preserved, but classes are often used in
scripts (e.g. a live table) and those scripts are not updated so there's a
high chance that something will not work correctly after the class rename.
WDYT?
Thanks,
Marius
Dear developers,
Now that we consider notifications as an achieved replacement for both
Activity Stream and the Watchlist, I propose to stop maintaining them and
to move them into the "attic" section.
You need to know that we had a dependency on the Activity Stream API, as
the only implementation of the Event Stream, on which the Notifications are
based. So to get rid of this dependency (the code is not using our
component system and is not well tested), I have written a new
implementation of the Event Stream that I have called "Event Stream Store".
It's fully backward compatible with the old implementation, since it is
using the same Database schema. In practice, I re-used some pieces of
Activity Stream that I have modified to fit into components. For more
information, see: https://jira.xwiki.org/browse/XWIKI-16052
So my proposal is this one:
- use the new store in 11.1
- stop bundle Watchlist and AS in 11.1
- move Watchlist and AS into "attic" in 11.2
Thanks you,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi devs,
As a follow-up to the issue below, I'd like to propose the creation of an extension for adding Open Graph Protocol support to XWiki pages :
https://jira.xwiki.org/browse/XWIKI-16087
Hence my request: would you approve the creation of an "application-open-graph-protocol" repository in xwiki-contrib, and an OGP project in JIRA?
Cheers,
Stéphane
--
Stéphane Laurière
XWiki www.xwiki.com
Hi everyone,
I'd like to propose an evolution of the livetable Excel export macro [1] so as to support CSV export, and possibly ODS in the future. I'm adding Anca and Guilhaume as original authors (and we discussed the idea with Anca). Since the existing macro name would not match with this new functional perimeter, my proposal would be to create a new macro that we could call "livetable exporter macro". This macro would be at first a copy of the existing one in order to keep the source code history tree, and then it would evolve on its own.
Hence my question: would you approve the creation of a "macro-livetable-exporter" repository on github.com/xwiki-contrib, and an LTEXP project in JIRA?
[1] <https://extensions.xwiki.org/xwiki/bin/view/Extension/LiveTableExcelExport Macro>
Regards,
Stéphane
--
Stéphane Laurière
XWiki www.xwiki.com