Export cmd bugfixes

[dlutz2]

Resolves [#1145, resolves #1144, resolves #1131]

• docs/ have been added/updated - no doc changes needed
• tests have been added/updated
• mvn verify says all tests pass
• mvn site says all JavaDocs correct
• CHANGELOG.md has been updated - minor changes

fixes #1145 - removed case statement looking for "equivalent annotation property", added test exporting all named headers, added test ontology containing one of all OWL axioms and class expressions, plus some puns
fixes #1144 - removed self-disjoint entry in returned entities
fixes #1131 - refactored to avoid creating unnecessary styles and fonts, added matching test

[matentzn]

@dlutz2 thank you so much for your contribution! I will try to find a reviewer for this now, forgive use that it may take a bit of time. Your work is highly appreciated!

[matentzn]

This is only a partial review now, because we have a big backlog for reviews. I asked a community member for a cursory review to get started, and this is what they said:

• The code does not follow, in some places at least, the “Google Java style” that is used by ROBOT.
• The fix for issue 1131 (export to Excel with > 64k rows) is only a partial one. The problem would still occur if there are more 64k rows with a non-null violationLevel, because the code still creates a new style for each cell in that case. That being said, the PR is a major improvement compared to the current situation where a new style is created for every cell, even those without a violation level. So I would still accept the fix while noting that it can be improved even further later on.
• For issue 1144, no comment except that (as already noted in the issue), maybe the proper fix belongs to the OWL API (the behaviour of EntitySearcher.getDisjointClasses() does seem wrong to me, or its documentation is misleading).

Let me know @dlutz2 what you think!

[matentzn]

As an amendment to the above from our collaborator @gouttegd:

ROBOT uses the com.coveo:fmt-maven-plugin Maven plugin to enforce its code style as part of the build process, so all you have to do is to check out the branch and do a simple build (or even just mvn process-sources if you don’t want to do a full build); then use git diff to check what changes the formatter made to the source.

For example:

-    for(short colIx=minColIx; colIx<maxColIx; colIx++) {
-       Cell cell = header.getCell(colIx);
-      if(cell == null) {
+    for (short colIx = minColIx; colIx < maxColIx; colIx++) {
+      Cell cell = header.getCell(colIx);
+      if (cell == null) {

This is also how the authors can fix their PR: all they have to do is to run mvn process-sources and commit the result.

[dlutz2]

Thanks for the review.
I'll look at the Excel issue with many non-null violation Levels and add that to the branch. (I assume that is the proper approach to amend a PR)
Sorry about the formatting. I'm using Eclipse on Windows and both the built in formatter and the google-java-format code seem to have issues. I had not looked at the Maven plugin and didn't realize it had formatting capability. Thanks for the pointer, I'll reformat and add that to the branch as well.

[dlutz2]

Another bit: Is there anything I can do to make the review easier (e.g. smaller PRs?) or is it just a matter of time/attention of the reviewers?

[gouttegd]

Regarding the formatting: if you’re using Eclipse, you may want to use the code style description file available here. This way Eclipse will automatically format the code using the expected style as you save it.

Regarding the Excel issue: as I noted, the PR is already a major improvement over the current situation, so I personally would be fine with accepting it as it is and leave any further improvement for another PR. That being said, if you do want to try to improve it right now, then of course feel free to do so!

[jamesaoverton]

Looks good! I'm very happy that we can now support up to 64k rows with violations, up from 64k total rows. If someone needs more than that, they can make another PR 😄. The additional tests are much appreciated!