Create example violations to show ArchUnit test in action

[hohwille]

We need to have Java code that violates the architecture rules and shows our ArchUnit test(s) in action.
For implementing this story, we should first think about the design as there are several options:

• create one project with a sample app and ArchUnit test as JUnit test for it including github CI action that is failing and red giving the summary of all architecture violations showing that the ArchUnit test is properly working by example
• create Java files for each ArchUnit test/rule and setup some test infrastructure that verifies that exactly expected issues are found in according Java files. See the sonar-devon4j-plugin for example that used such approach:
  • https://github.com/devonfw/sonar-devon4j-plugin/blob/master/plugin/src/test/files/layer/DevonArchitectureLayerDataaccess2LogicCheck.java
  • https://github.com/devonfw/sonar-devon4j-plugin/blob/master/plugin/src/test/java/com/devonfw/ide/sonarqube/common/impl/check/layer/DevonArchitectureLayerDataaccess2LogicCheckTest.java

[Bene90]

Info:
This taks is relevant for everyone.

[hohwille]

I missed to review the first draft PR in all details:

-@AnalyzeClasses(packages = "com.devonfw.sample.archunit", importOptions = ImportOption.DoNotIncludeTests.class)
+@AnalyzeClasses(packages = "com.devonfw.sample.archunitviolations", importOptions = ImportOption.DoNotIncludeTests.class)

IMHO it is not a good idea to change any of the JUnits in a draft PR demonstrating violations.
We should use the regular package namespace of our demo to show the violations in action.

• https://github.com/devonfw-sample/archunit/pull/16/files
• https://github.com/devonfw-sample/archunit/pull/12/files

Fortunately this pattern was not followed by all others when creating violation PRs.

[hohwille]

Draft PRs had been created. However, I will do some rework later with the following aspects:

• move them to feature branches directly in this repo rather than on external forks
• remove any changes to the tests themselves but only add new code in main with violations to existing package
• ensure completeness (all rules shall be covered) and alignment (PR per *Rules)
• consider making the violations more representable (e.g. show real SQL injection vulnerability)