Reduce code duplication down to 16 lines per piece

[c71n93]

Related to #2863

---

PR-Codex overview

This PR updates Simian configuration and improves logging in EOlang codebase.

Detailed summary

• Updated Simian threshold to 16 from 25
• Improved error messages in EOrust.java
• Refactored printing logic in EOstdoutTest.java
• Enhanced logging in DataizedTest.java

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[yegor256]

@c71n93 what's up with this one? still a draft?

[c71n93]

@yegor256 still working on it

[c71n93]

@maxonfjvipon could you check this one, please?

[c71n93]

@maxonfjvipon could you check this one, please?

[levBagryansky]

@c71n93 I am not sure that uniting of these lines is real solution of the duplication problem

String.format(
    "Object inside %s has wrong class %s",
    src,
    result.getClass()
)

[maxonfjvipon]

@c71n93 looks good. Even if you're not sure, the final result speaks for itself

[c71n93]

@c71n93 I am not sure that uniting of these lines is real solution of the duplication problem

String.format(
    "Object inside %s has wrong class %s",
    src,
    result.getClass()
)

@levBagryansky Yes, but I don't see any other options. This methods are located in different independent subprojects (eo-maven-plugin and eo-runtime).

The only solution I see is to create a dependency between subprojects (or create some eo-util which all subprojects will depend on). But as I know, this option is unacceptable. Maybe you have any other ideas?

[maxonfjvipon]

@c71n93 eo-runtime must stay independent of any other libraries at all, here is why

[c71n93]

@yegor256 could you please check this one?

[c71n93]

@c71n93 eo-runtime must stay independent of any other libraries at all, here is why

@maxonfjvipon I see

[levBagryansky]

@maxonfjvipon As for me, it's not so bad to create a component on which eo-runtime and eo-maven-plugin would depend. It's just that when implementing it, we should not allow cyclic dependencies(Acyclic dependencies principle) and that it should be more stable than components dependent on it (Stable Dependencies Principle).

[maxonfjvipon]

@levBagryansky in the process of compilation eo program we download eo-runtime as jar package, but we don't download its dependencies (fat jar). It's by design. That's why it should be independent.

[yegor256]

@c71n93 maybe it's better to slightly change the message?

[yegor256]

@c71n93 same here: maybe it's better to slightly change the message?

[c71n93]

@c71n93 same here: maybe it's better to slightly change the message?

@yegor256 done

[levBagryansky]

@maxonfjvipon Such architecture violates SRP: Maintaining of the map deserialization is in different classes, even in different modules. Whatever tests we write here, this code will fall off the user in production one day and we will all be fired.

[maxonfjvipon]

@levBagryansky then I can ask, why are they in different modules? Maybe it's the main problem? Because you're offering to sacrifice eo-runtime independence (which has highest priority) for the sake of the SPR and your convenience

[levBagryansky]

@maxonfjvipon That's how they should be in the same module. The architecture does not allow this to be done.

[yegor256]

@rultor merge

[rultor]

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

[rultor]

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 22min)