Add parse and compare hooks

[olmokramer]

This adds 4 hooks that can be set on the JPlagOptions class:

• A pre-parsing stage hook, which is called before all submissions are parsed. It is called with the list with all submission paths eligible for the comparison, i.e. all paths that are not filtered out by SubmissionSetBuilder.isExcludedEntry.
• A post-parsing hook per submission, which is called after the submission has been parsed. It is called with the Submission object that has been parsed.
• A pre-comparing stage hook, which is called before the comparisons are started. It is called with a list of all comparison tuples.
• A post-comparing hook, which is called after each comparison. It is called with the SubmissionTuple that has just been compared.

The default for each hook is to do nothing.

For some background, we are using JPlag for plagiarism checking and want to be able to track the progress of the plagiarism check (e.g. the percentage of submissions that have already been parsed, or the amount of pairs that have already been compared). With these hooks we can implement that, but simultaneously they might be used for other unforeseen use cases.

Looking forward to feedback on the concept and the implementation.

[dfuchss]

I've made a short code review and supplied some suggestions, feel free to comment on them :)

[olmokramer]

@dfuchss Thank you for the review! I've applied most of your suggestions and replied to your comments if I did not.

[dfuchss]

@olmokramer thanks a lot. Could you please resolve the code smells as well :)

EDIT: I've retriggered SonarCloud .. let's wait for the results :)

[olmokramer]

@dfuchss thanks. I've now added some test cases for all the hooks as well.

[dfuchss]

Thanks for the tests. I've one minor suggestion regarding them.

[dfuchss]

I think the idea and realization is good.
Maybe you can add some docs to the public methods/fields you've created.

Afterwards, let's wait for the review of @tsaglam :)

[dfuchss]

Some tests seem to fail :)

[olmokramer]

@dfuchss Thanks again for the reviews. I have added documentation for the new fields on the JPlagOptions class.

Some tests seem to fail :)

Whoops, shouldn't have copy-pasted that test... Fixed now :)

[tsaglam]

Sorry for my absence, I was out of office. I will take a look at it as soon as I can find the time!

[sonarqubecloud]

[JPlag Plagiarism Detector] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[olmokramer]

@tsaglam Have you already had a chance to take a look at this?

[tsaglam]

Have you already had a chance to take a look at this?

Sorry, I am currently swamped and probably will be until the end of November.
For now, I will have @TwoOfTwelve take a look to keep the ball rolling.

[olmokramer]

Thank you for your response and good luck with your work the upcoming month :-)

[TwoOfTwelve]

@olmokramer
I have talked with Timur about your code. There are a couple of thinks we agreed are not good for the architecture of JPlag. The major points are:

1. The JPlagOptions class is expanded further, but is already very big and clunky.
2. JPlagOptions has a dependency on Submission and some other types, which should not happen
3. Hooks are not really options for JPlag
4. The JPlag code get coupled tightly with the hooks
5. There is a central list of available hooks, which would make it hard to expand them in the future

I have implemented a suggestion on how we could handle the hooks in the feature/hooks branch. Please take a look on that an tell me what you think. In particular if it fulfills all your requirements. Right now it is still in a rough state and I only implemented one hook as an example. If you like the idea, I would leave it up to you how we proceed. If you want you can change your implementation (or make a new one), or I could finish my changes on feature/hooks.

I am sorry for any inconvenience this might cause you. We do appreciate your work, we are just trying to keep our architecture as clean as possible.

[olmokramer]

@TwoOfTwelve thank you for the review! This is exactly the kind of feedback I was looking for :) I agree with the points you brought up and that the current implementation is not necessarily the best for the JPlag architecture.

I'm also on a quite tight schedule, so I don't know when I will have time to take a look at your suggested implementation. We are running a build of our fork with this PR, so there's no real rush from our side to get this in. I'd rather get it done in a way that is maintainable and sustainable. I'll try to make some time next week, though, to take a look.

Our requirements are not very complex. In particular, we need to be able to

• get the total amount of submissions that will be parsed, before parsing has started. Though it would also be fine to get this information as soon as the first submission has been parsed. (This is what the preParseHook in this PR is for).

• update a counter as soon as a submission has been parsed. (This is what the parseHook in this PR is used for)

• get the total amount of comparisons that will be made, before comparing has started. Though here too it would be fine to get this information directly after the first comparison. (This is what we use the preCompareHook from this PR for)

• update a counter as soon as a comparison between 2 submissions has finished. (We use the compareHook from this PR for that)

Thanks again for you consideration.

[tsaglam]

Superseded by #1433. Let us know if additional requirements come up.