Ignore Patterns on message is too greedy about archunit HOT 6 CLOSED

I know the ignore_patterns.txt is pretty crude, e.g. often it would be better to be able to customize this per rule. However, I have no clear vision yet, what would be necessary, and in which form it could be provided. Maybe I need to collect some more use cases.
In your case though, couldn't you solve your concrete problem by specifying more of the message? For example sth. like

class .*(IgnoredClassOne|IgnoredClassTwo) (calls|accesses) .*

to ignore all violations originating from certain classes you want to ignore?
I think a more structured format might be good, to specify origins or targets, but some rules also don't have these concepts (like class has wrong name).
That is why so far I haven't added a more sophisticated way to ignore violations.

In my project we often ignore this programmatically, like

@Test
public void foo() {
    ArchRule rule = ignoreKnownViolations(classes().that())...should()...
}

private GivenClassesThat ignoreKnownViolations(GivenClassesThat classesThat) {
    for (String fqn : classesToIgnore) {
        classesThat = classesThat.dontHaveFullyQualifiedName(fqn).and();
    }
    return classesThat;
}

Of course in these cases you probably need to overwrite the generated rule text 😉

from archunit.

I agree with your points, there is definitely room for improvement here. However, as you say, it's more than this issue was originally about, so I've opened a new one: #66
Do you find your points correctly reflected there?
If yes, I'd close this issue and move discussion / implementation over to the new one.

from archunit.

Was this sufficient for your use case, or do you have any suggestion, how the ignore patterns should be improved?

from archunit.

If there's no suggestion, how the ignore patterns could be improved, I'll close this issue for now, until something more concrete will come up.

from archunit.

Thanks @codecholeric for your long and helpful answer. It might be more than this issue was originally about:

Ignoring is difficult because the message could be freely defined, this is of course hard to maintain. But I must admit that my problem was not directly the Regex itself, but that it was not really visible for me that the Regex was the problem root. Archunit gave no feedback that it ignored the Error. I thought something in my expression was wrong; only after debugging I discovered the true mechanism of the regex. A simple idea could be to print out a log message that this error violation was omitted. One can say that the current status is as it is intendent, but maybe this could be lead to something else.

The whole idea of ignoring issues comes from the point that old/large code parts cannot be refactored in a story or sprint. But nevertheless, it might be interesting to be aware of such violations in a form of a report. This could be in the end an HTML file, similar to what JGiven offers. Archunit has the concept of Priorites. The report could list all violations but fail the test only if it is defined as a test of given priority.

from archunit.

Thanks for the follow up. I close the Issue.

from archunit.