Feature/normalization option

[TwoOfTwelve]

Implemented the cli (and JPlag) option to enable normalization.
If normalization is enabled, but not supported for the selected language JPlag immediately throws an exception.

The help text also shows, if normalization is supported for a language:

  cpp         supports normalization: false
  cpp2        supports normalization: true
  csharp      supports normalization: false
  emf         supports normalization: false
  emf-model   supports normalization: false
  go          supports normalization: false
  java        supports normalization: true
  kotlin      supports normalization: false
  llvmir      supports normalization: false
  python3     supports normalization: false
  rlang       supports normalization: false
  rust        supports normalization: false
  scala       supports normalization: false
  scheme      supports normalization: false
  scxml       supports normalization: false
  swift       supports normalization: false
  text        supports normalization: false
  typescript  supports normalization: false

(relates to #1028)

[Kr0nox]

Since the README and wiki contains the help text, this PR should probably updates those

[tsaglam]

A few minor issues here.

[tsaglam]

Good for now, when we enable it for EMF, we need a language method that can be called for the normalization.

[tsaglam]

@TwoOfTwelve Do you want to make the changes regarding the language interface in this PR, or should I merge?

[TwoOfTwelve]

I would like to do the changes to the Language interface here. I should get this done today.

[TwoOfTwelve]

@tsaglam I have implemented a rough solution. Please take a look at it. I know it is still lacking all documentation, but I would like to know what you think before putting any more time into this.

Basically, in langauge-api/standardOptions the StandardOptionsLanguage and the NormalizatbleLanguage classes contain a bunch of ungly code. Also there will be runtime exceptions if the interface is used without the abstract class. I think it is worth it, because it is the most flexible solution and also gives us an infrastructure for more options shared between languages.

[tsaglam]

@TwoOfTwelve

Basically, in langauge-api/standardOptions the StandardOptionsLanguage and the NormalizatbleLanguage classes contain a bunch of ugly code. Also there will be runtime exceptions if the interface is used without the abstract class.

Agreed, that is not ideal from my point of view.

I think it is worth it, because it is the most flexible solution and also gives us an infrastructure for more options shared between languages.

I do not think so, as it introduces a lot of complexity just to prematurely plan for future use cases.
I think I prefer the lightweight option we discussed in the last meeting where we just provide a version of the parse method that supplies the language module with the information if normalization was enabled or not.

List<Token> parse(Set<File> files, boolean normalizationRequested) throws ParsingException;

default List<Token> parse(Set<File> files) throws ParsingException {
	parse(files, false);
}

This is minimally invasive and should not be API breaking through the default option.

[tsaglam]

Just the minor issue we discussed regarding the language interface. Coverage is fine in this PR.

[tsaglam]

@TwoOfTwelve now you know why I was thinking about replacing as much code as possible in the Scala module with Java code! :D

Coverage is fine for me, spotless needs a minor fix.

[sonarcloud]

Quality Gate failed for 'JPlag Plagiarism Detector'

Failed conditions
47.1% Coverage on New Code (required ≥ 50%)

See analysis details on SonarCloud