societe-generale / arch-unit-build-plugin-core Goto Github PK

Summary

The plugin logs everything via INFO level, thereby polluting maven builds with tens of thousands of unwanted lines.

Type of Issue

• bug

Motivation

Be able to read my Maven build output.

Current Behavior

[INFO] just built com.my.package.Rules :
[INFO] 1 field rules loaded
[INFO] public static final com.tngtech.archunit.lang.ArchRule com.my.package.Rules.NAME_RULE
[INFO] 0 method rules loaded
[INFO] invoking ConfigurableRule ConfigurableRule(rule=com.my.package.Rules, applyOn=com.societegenerale.commons.plugin.model.ApplyOn@701996e9, checks=[], skip=false) on C:\dev\com.my.bundle.tests\target - /classes/com/my/package
[INFO] Detected Java version 1.8.0_201
[INFO] applying rules on :
[INFO] com.some.package

And then follows a list of thousands of classes.

Expected Behavior

Separate log output for end users of your plugin (INFO level) and developers of your plugin (DEBUG level). Especially don't log any lists/collections via INFO level, since that does never scale.

Steps to Reproduce (for bugs)

Run with custom rule on a large code base.

Summary

there are 3 SYstem.out.println calls in

committed by mistake after debugging an issue

Type of Issue

It is a :

• [x ] bug
• request
• question regarding the documentation

• Version used: 2.5.1

Summary

There seems to be an issue with the version 2.9.1 where even if we do not have a class prefixed with I still we get

ArchUnit Maven plugin reported architecture failures listed below :Rule Violated - com.societegenerale.commons.plugin.rules.NoPrefixForInterfacesRuleTest
[ERROR] java.lang.AssertionError: Rule 'classes that are interfaces should not be prefixed with I - this is a .Net convention.' failed to check any classes. This means either that no classes have been passed to the rule at all, or that no classes passed to the rule matched the `that()` clause. To allow rules being evaluated without checking any classes you can either use `ArchRule.allowEmptyShould(true)` on a single rule or set the configuration property `archRule.failOnEmptyShould = false` to change the behavior globally.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Current Behavior

Fails the build

Expected Behavior

Should build successfully

Steps to Reproduce (for bugs)

devs-from-matrix/hexagonal-spring-boot-java#231

Your Environment

• Version used: 2.9.1
• OS and version: Mac 11.5.1

Summary

We bumped our dependency versions to latest . For example : spring-boot which uses jakarta in place of javax. While we did that , the rule com.societegenerale.commons.plugin.rules.DontReturnNullCollectionTest is violated. Because the rule is checking for javax and not jakarta.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

Steps to Reproduce (for bugs)

Build a new spring boot to violate the DontReturnNullCollectionTest and then annotate with @Nonnull imported from jakarta.

Your Environment

• Version used:3.0.0
• OS and version:Windows 11

Summary

mvn com.societegenerale.commons:arch-unit-maven-plugin:2.9.2:arch-test -DskipTests -Dorg.slf4j.simpleLogger.showLogName=true 

[WARNING] com.societegenerale.commons.plugin.maven.ArchUnitMojo - classpath foo/bar doesn't exist : loading all classes from root, ie  even though it's probably not what you want to achieve..
[WARNING] com.societegenerale.commons.plugin.maven.ArchUnitMojo - existing folders and files under root project :
[WARNING] com.societegenerale.commons.plugin.maven.ArchUnitMojo -
[WARN] Maven__com_fasterxml_classmate_1_3_4.xml
[WARN] Maven__com_fasterxml_classmate_1_5_1.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_annotations_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_annotations_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_annotations_2_12_2.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_annotations_2_12_5.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_annotations_2_9_0.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_core_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_core_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_core_2_12_5.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_databind_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_databind_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_databind_2_12_2.xml
[WARN] Maven__com_fasterxml_jackson_core_jackson_databind_2_12_5.xml
[WARN] Maven__com_fasterxml_jackson_dataformat_jackson_dataformat_csv_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_dataformat_jackson_dataformat_xml_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_dataformat_jackson_dataformat_yaml_2_11_1.xml
[WARN] Maven__com_fasterxml_jackson_dataformat_jackson_dataformat_yaml_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_datatype_jackson_datatype_jdk8_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_datatype_jackson_datatype_jdk8_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_datatype_jackson_datatype_jsr310_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_datatype_jackson_datatype_jsr310_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_datatype_jackson_datatype_jsr310_2_12_1.xml
[WARN] Maven__com_fasterxml_jackson_jaxrs_jackson_jaxrs_base_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_jaxrs_jackson_jaxrs_base_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_jaxrs_jackson_jaxrs_base_2_9_10.xml
[WARN] Maven__com_fasterxml_jackson_jaxrs_jackson_jaxrs_json_provider_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_jaxrs_jackson_jaxrs_json_provider_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_jaxrs_jackson_jaxrs_json_provider_2_9_10.xml
[WARN] Maven__com_fasterxml_jackson_module_jackson_module_jaxb_annotations_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_module_jackson_module_jaxb_annotations_2_11_4.xml
[WARN] Maven__com_fasterxml_jackson_module_jackson_module_jaxb_annotations_2_9_10.xml
[WARN] Maven__com_fasterxml_jackson_module_jackson_module_parameter_names_2_11_3.xml
[WARN] Maven__com_fasterxml_jackson_module_jackson_module_parameter_names_2_11_4.xml
[WARN] Maven__com_fasterxml_uuid_java_uuid_generator_3_2_0.xml
[WARN] Maven__com_fasterxml_woodstox_woodstox_core_6_2_1.xml
[WARN] Maven__com_fasterxml_woodstox_woodstox_core_6_2_3.xml
[WARN] Maven__com_fasterxml_woodstox_woodstox_core_6_2_4.xml
...
[WARN] f4
[WARN] 07fc0e772114902c6e4ce86ca693cb4dd739e8
[WARN] 4a09dae51952773bbd5eb7ba78d026034e4d72
[WARN] f5
[WARN] 7dacac98852078c4469cf57bf010b1f1042467
[WARN] 9dbb6afb02c3df99122a8720d214cf70bf648b
[WARN] a78f878a02580d1ebd2aded36f856945bc58a8
[WARN] ca0316f2cebdb6afb407f4768e0e8e4ad3dda0
[WARN] f6
[WARN] 4b0eea5f4a5ab08795c72fdebdb771a8df3bc3
[WARN] c400522a9bb811f611bdeb671e965de78ba827
[WARN] f7
[WARN] 1a0b55870de79ac00ea0a2368daf4c71dae304
[WARN] 72f4d9ae1b1f880d1c5f65a8db782b9913ade6
[WARN] 751fe7744f8db7e70b93fee66517834ec3071d
[WARN] f8
[WARN] 5b768c1099b2ea4891bb2e53c3c2a9a36a145f
[WARN] 705bd83f9465a7fdb85b49e80032db19866a6c
[WARN] f9
[WARN] 726c5007ff9bcf255f0b0ce58118aa0f76fddc
[WARN] 7635251ad368b68da82d120575ab20355cf806
[WARN] ee6d6a2d8fe52939fad50f2125cb957fdb9c00
[WARN] fa
[WARN] 2567a4f1580762bebb1961a55b6c2f98f33e4d
[WARN] 9c5842a191eb01f37fc2acecd7e2e46200ef8b
[WARN] fc
[WARN] 81cc15fe6230164afdf4f48fd295684d2f5d68
[WARN] aee828879e19043d70b42cba02cc5d04303074
[WARN] fd
[WARN] 1fdda041c6ae7612f8266d6e109ca3c22c7550
[WARN] 6e2ef95c45f9f7be554e3f539d00f88ef099ad
[WARN] 79433e4ea23d5baf613543d1fbd18ae8c9a753
[WARN] ca47848dc7ac94115c0a27a39f797900386ad6
[WARN] fe
[WARN] 6d3003f753ec612237501852f5d4fd7ec6c3a2
[WARN] 8d6dfd66f442e84c017ec769f32971524b2a59
[WARN] d21f00f8854c2780db4093e09e71f875daf505
[WARN] d3dfdd824cd393107e543eae77d688cffda0dc
[WARN] ff
[WARN] 359f8e29df48c019bcbad36ffa38e98f555bde
[WARN] 64a92b19de79fe26130946f9017738522c75ab
[WARN] 9dcea14178b7f180c4e0548a5c9b931b9708cb
...

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

Current Behavior

In my multi-module project, there are some projects which don't follow the package naming convention, hence I get this warning, which is ok.
What's not ideal is that I get a single-line warning for each resource, which means my log is cluttered with thousands of lines of warnings.

Expected Behavior

A single warning is printed with all relevant resources, ideally shortened.
I think an easy fix would probably replacing the foreach for a collect, or changing the log level to e.g. debug.
https://github.com/societe-generale/arch-unit-build-plugin-core/blob/master/src/main/java/com/societegenerale/commons/plugin/utils/ArchUtils.java#L51

Your Environment

• arch-unit-maven-plugin: 2.9.2

Summary

Please consider supporting that a configurable rule can be a grouping of rules.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

Basically, given

class AllRulesTest {

    @ArchTest
    static final ArchTests SOME_RULES = ArchTests.in(SomeRules.class);

    @ArchTest
    static final ArchTests OTHER_RULES = ArchTests.in(OtherRules.class);
}

it would be nice that the Maven plugin would pick up all the rules via

(...)
<rules>
  <configurableRules>
      <configurableRule>
          <rule>package.AllRulesTest</rule>
      </configurableRule>
  </configurableRules>
</rules>
(...)

instead of having to do

(...)
<rules>
  <configurableRules>
      <configurableRule>
          <rule>package.SomeRules</rule>
      </configurableRule>
      <configurableRule>
          <rule>package.OtherRules</rule>
      </configurableRule>
  </configurableRules>
</rules>
(...)

Current Behavior

Grouping is ignored (rules referred to by ArchTests are not taken into consideration).

Currently it looks like grouping is not supported in InvokableRules.

Expected Behavior

Grouping works via the plugin just as if run as a test directly.

Steps to Reproduce (for bugs)

If the above is not clear, I can provide a sample.

Your Environment

ArchUnit 1.0.1
arch-unit-maven-plugin 3.0.0

to avoid this :

Summary

com.societegenerale.aut.main package also contains classes for tests. Maybe, they should be move to com.societegenerale.aut.test package.

To make the code more readable, I suggest to create sub package in com.societegenerale.aut.test for each rule we create.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Summary

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

I have implemented a solution for the "exclude generated-sources feature request" (societe-generale/arch-unit-maven-plugin#33) but there is a little problem with ExclusionImportOption#includes method.
The include check is based on a file path. My solution generates a package path as exclude pattern and so ExclusionImportOption#includes always returns true.

My request is it to extend the include check with some kind of package check.

Current Behavior

 @Override
    public boolean includes(Location location) {

        if(location.contains(patternToExclude)){
            return false;
        }
        return true;
    }

Expected Behavior

 @Override
    public boolean includes(Location location) {

       if(location.contains(patternToExclude) || location.contains(patternToExclude.replaceAll("\\Q.\\E", File.separator)){
            return false;
        }
        return true;
    }

Summary

Wenn resolving the fullPathFromRootTopackage for configurableRules the path is wrong calculated when the ScopePathProvider delivers a path with dots.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

When using the Maven Plugin in a Multibranch Pipeline with branch names like minor-1.2 the full classpath is wrong calculated.

Current Behavior

the path on the filesystem for a branch with name minor-1.2 is calculated to minor-1/2/target/test-classes

Expected Behavior

the path from the ScopePathProvider should not be replaced. the right path is minor-1.2/target/test-classes

Steps to Reproduce (for bugs)

see Testcase in PullRequest

Your Environment

• Version used: 2.7.0
• OS and version: Linux

Summary

Have the possible to have inheritance in configurable rules and the invocation is donne on the master class(abstract).
In this case only on method is call.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

• The advantage is that it allows to apply actions for all rules that implement for example an abstract class.
• Less duplication of code.

Current Behavior

Now only the declared methods is invoke.

Propsition: https://github.com/societe-generale/arch-unit-build-plugin-core/compare/master...magori:InvokeConfigurableRuleMethodWithInheritance?expand=1

Summary

[0.23.0 changelog of ArchUnit|https://github.com/TNG/ArchUnit/releases] mentions:

ArchRules will now by default reject evaluating if the set passed to the should-clause is empty. This prevents implementation errors like picking a package in that()... that doesn't even exist and thus composing a rule that doesn't check anything (compare the user guide; see TNG/ArchUnit#774; thanks a lot @oberprah)
[...]
You can restore the old behavior by setting the ArchUnit property archRule.failOnEmptyShould=false

Type of Issue

It is a :

• bug / regression
• request
• question regarding the documentation

Motivation

Being able to define rule set in parent Maven file without knowing in advance if the module will contain classes satisfying the test.

Current Behavior (since 2.9.0)

• <rule>com.societegenerale.commons.plugin.rules.TestClassesNamingRuleTest</rule>
  fails on modules with no test classes
• <rule>com.societegenerale.commons.plugin.rules.NoPrefixForInterfacesRuleTest</rule>
  fails on modules without interfaces
• etc

Expected Behavior (in 2.8.0)

Build succeeds on modules without Java classes as well as on the ones which do not satisfy the "that" conditions of all defined rules in the build configuration.
i.e. set globally archRule.failOnEmptyShould = true for this build-plugin

Steps to Reproduce (for bugs)

See "current behavior"

Your Environment

• Version used:
• OS and version:
• Version of libs used:

Summary

in HexagonalArchitectureTest, we currently check no call is performed to packages not explicitly authorized :

However, a class in domain annotated with a an annotation from a not authorized package (com.fasterxml.jackson.annotation.JsonIgnoreProperties) will not be caught !

Summary

We regularly see date fields that are not typed properly. however, it's quite easy to identify them by name, because they usually finish by "Date", like

String startDate

we need a rule that will look at all the class's String fields : if one of those fields ends by "Date", throw an exception that says :

field "startDate" is a String, but it seems to be a Date : if it really is a Date, please change its type accordingly, Strong typing helps write more meaningful code.

Summary

Pre-configured rule ConstantsAndStaticNonFinalFieldsNamesRuleTest cannot be used if the project contains serializable classes having a final static field called serialVersionUID (as per the Serializable class documentation). The only remaining choice seems to either not use this rule, or not care about serializability of the project classes.

Is it possible to have a pre-configured rule which ignores the static final fields which are expected by java.io.Serializable (servialVersionUid and serialPersistentFields)?

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

If the project contains a serializable class which follows the recommendation of declaring a static final field called serialVersionUid (https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html), and the project otherwise wants to enforce the convention of having constants in uppercase, then the build plugin will throw the following exception:

[ERROR] java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule 'fields that are declared in classes that are not enums and are static and are final should be In UpperCase And Use Underscore' was violated (1 times):
[ERROR] Constants have to be written in uppercase. It's possible to add underscore but not at the beginning or the end of the name. - class: com.example.service.MyExampleService - field name: serialVersionUID

Since renaming the field would be the same as deleting it and foregoing the goal of defining the serialization version manually, the rule suggestion cannot be followed and the rule must be removed for projects following the Serializable recommendation...
The last option is for all projects using serialization to have the same custom rule. What a shame!

It would be great if arch-unit-build-plugin-core could offer a default pre-configured rule which does not throw assertion errors for Java special fields.

Summary

It looks like this issue triggered with the Maven plugin, is caused by a general problem:

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.base/java.lang.String.substring(String.java:1837)
        at com.societegenerale.commons.plugin.service.JavaFileParser.extractClassName(JavaFileParser.java:124)
        at com.societegenerale.commons.plugin.service.JavaFileParser.parse(JavaFileParser.java:44)
        at com.societegenerale.commons.plugin.service.ExcludedPathsPreProcessor.determineClassNames(ExcludedPathsPreProcessor.java:194)
        at com.societegenerale.commons.plugin.service.ExcludedPathsPreProcessor.processExcludedPaths(ExcludedPathsPreProcessor.java:65)
        at com.societegenerale.commons.plugin.service.RuleInvokerService.<init>(RuleInvokerService.java:49)
        at com.societegenerale.commons.plugin.maven.ArchUnitMojo.execute(ArchUnitMojo.java:94)
        ... 13 common frames omitted

I think the core module should handle this case gracefully, and provide means to debug it, even if may not directly lead a resolution of the issue triggered in the Maven plugin.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Current Behavior

Passing file content that contain class only in a comment, leads to the process being aborted, with no additional information to resolve the issue.

Expected Behavior

The core module should provide constructive feedback, and proceed with the next file.

Steps to Reproduce (for bugs)

See societe-generale/arch-unit-maven-plugin#49

Your Environment

See societe-generale/arch-unit-maven-plugin#49

What is the issue ?

Assume we have a project structure like where you do not have src/main

when we use arch-unit plugin it defaults to target or build if src/main or src/test is missing

[WARNING] classpath /Users/paulwilliams/Desktop/WORKSPACE/DFM/hexagonal-spring-boot-java/acceptance-test/target/classes doesn't exist : loading all classes from root, ie /Users/paulwilliams/Desktop/WORKSPACE/DFM/hexagonal-spring-boot-java/acceptance-test/target even though it's probably not what you want to achieve..
[WARNING] existing folders and files under root project : 
[WARNING] target

In this case violations like NoAutowiredFieldTest fails because it is unable to know whether it is src/main or src/test. Even through it should be only for main class path https://github.com/societe-generale/arch-unit-build-plugin-core/blob/master/src/main/java/com/societegenerale/commons/plugin/rules/NoAutowiredFieldTest.java#L24

How to produce ?

• Checkout code from https://github.com/devs-from-matrix/hexagonal-spring-boot-java
• maven clean install
• The logs should have the details

Summary

NoTestIgnoreRuleTest should also flag @ArchIgnore annotations without a provided reason

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

Currently NoTestIgnoreRuleTest only checks for JUnit 4's @Ignore and JUnit 5's @Disable, but does not check for ArchUnit's @ArchIgnore annotation.

Summary

The return of the method RuleInvokerService::invokeRules is a string. Can it be a list of object with information like:

• Rule name
• Error message
• Others (like filename, line, etc.) but it seems harder to code

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

This behavior can be usefull to create a post-error analysing process. It can be use by arch-unit-maven-plugin to have maven report or csv output.

Summary

This package contains two objects related to NoPublicFieldRuleTest that are already present in
com.societegenerale.aut.test. Should not we delete those duplicated objects ?

Furthermore what's the role of com.societegenerale.commons.plugin.rules.classesForTests ? It looks like it should contain classes for tests but other packages work fine.

Should we delete this package ?

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

looking at build logs, it seems tests are nt executed anymore !!

Summary

A new configuration point for ConfigurableRules could be very useful to specify whether a rule is frozen or not.
See https://www.archunit.org/userguide/html/000_Index.html#_freezing_arch_rules for reference documentation.

I'm particularly interested in this feature in the Gradle plugin, but this feature could totally benefit the Maven plugin as well, which is why I've created this request here.

Type of Issue

It is a :

• bug
• request
• question regarding the documentation

Motivation

When it comes to implementing ArchUnit in existing projects, the Freezing rules feature is very useful for implementing an iterative approach.

As it is, I haven't found any workaround other than declaring each rule twice, once "normally", and once wrapping it with FreezingArchRule.freeze(rule). By doing this, it is then possible to decide in the plugin configuration whether to use the "normal" rule or the frozen rule. In the meantime, if anyone sees a better workaround, don't hesitate to share :-)

A new configuration point in ConfigurableRules seems to me more appropriate for deciding whether a rule is frozen or not. WDYT?

Current Behavior

archUnit {
   configurableRules=[
      configurableRule(
         "com.societegenerale.commons.plugin.rules.NoAutowiredFieldTest", 
         applyOn("com.package","main")
      ),
   ]
}

Expected Behavior

archUnit {
   configurableRules=[
      configurableRule(
         "com.societegenerale.commons.plugin.rules.NoAutowiredFieldTest", 
         applyOn("com.package","main"),
         true <== true for frozen, false otherwise, defaults to false
      ),
   ]
}

Your Environment

• Version used:

  • com.societegenerale.commons:arch-unit-gradle-plugin:2.9.5
  • com.societegenerale.commons:arch-unit-build-plugin-core:2.9.5

• OS and version: MacOS Ventura (13.5.1)

Summary

since Junit 5 is using another annotation than @ignore (see https://junit.org/junit5/docs/current/user-guide/#writing-tests-disabling), https://github.com/societe-generale/arch-unit-build-plugin-core/blob/master/src/main/java/com/societegenerale/commons/plugin/rules/NoTestIgnoreRuleTest.java won't catch anything

tests are still using Junit 4... time to upgrade !