Freezing rules issues on windows/non-windows environments

[stefanroeck]

The default violation storage uses the textual description of violating rules as key. The description of LayeredArchitecture rules however use linebreaks in their text to separate the layer description which is nice on the console but leads to issues when running the same rules on windows and linux environments, as both rule violations are not considered as equal anymore (\r vs. \r\n).

A quick and dirty fix could be to replace any kind of linebreak inside of the FreezingRule, but one could also rethink if using the rule description is a good key or something more stable should be used instead.

[stefanroeck]

Looking into the source code, com.tngtech.archunit.library.freeze.ViolationLineMatcher seems to tackle a similar problem, so this could also be a place to "fix" this. Or more robust solution could allow to provide an explicite rule key, similar to Sonar's squid: ids and use that to reference rules.

[codecholeric]

Thanks for raising the issue! Yes, I can remember I had to tackle this in ViolationLineMatcher 😉 And it would certainly not be too hard to fix this for the rule text as well 🤔
As to your idea to use something like squid, I'm not sure I understand how to apply this. Wouldn't that require the rules to be from a fixed limited set? I.e. known in advance? Or in other words, if ArchUnit rules are completely free to design (both in what predicates/conditions they apply and the description they contain), how would there be deterministic IDs that are more robust than the rule description itself?
If there is a fixed set of provided rules it's easy, but ArchUnit essentially is just a rule toolkit, so until now I had no better idea how to identify a rule as by the mere description (including all the drawbacks).

[stefanroeck]

If there is a fixed set of provided rules it's easy, but ArchUnit essentially is just a rule toolkit, so until now I had no better idea how to identify a rule as by the mere description (including all the drawbacks).

I agree, this is tricky. The id somehow needs to be calculated for each violation by considering all related criteria. If there's a source-code location, this could be used, if there's a cycle of classes or so, maybe create a hash of all related class names or so? Technically, ConditionEvent could be the place where this id needs is attached to, would you agree?

[codecholeric]

Sorry, I got sucked off this by some other issues 😞 I'll try to fix the concrete pain point together with #508 now, i.e. ignore line breaks in the key.

About the id I'm still not completely sure. Because I don't see how the id of a rule can be connected to concrete violations (like a cycle), if the whole point of FreezingArchRule is to track the development of violations over time. It's the typical case that the violations will change, while the id needs to stay the same, right? So I think what would be needed is a fixed id that is more stable than the rule text, yet is only dependent on the rule itself without any connection to the actual violations which change over time 🤔

Anyway, I'll fix the symptom at hand, maybe at some point inspiration will strike how to do it in a smarter way 😄