ArchUnit 0.10.2

Bug Fixes

• Fixed JavaPackage.getPackageDependenciesFromSelf() containing the package itself if there was a dependency in the same package but not directly imported (e.g. importer.importClasses(Foo.class) where some.pkg.Foo would depend on some.pkg.Bar, which was not imported)

Enhancements

Core

• Some methods now return Collection types instead of Iterable to integrate nicer with streams

Lang

• FieldsShould now contains the negation notHaveRawTypes (see #162; thanks a lot to @asbachb)
• CodeUnitsShould now contains the negations notHaveRawParameterTypes, notHaveRawReturnType and notDeclareThrowableOfType
• The syntax now contains {methods,fields}().should().{be,notBe}{Static,Final} (see #164; thanks a lot to @hankem)

Library

• Slice now also offers dependenciesToSelf additionally to dependenciesFromSelf

Further Acknowledgement

• Thanks a lot to @hankem for reviewing and improving the user guide

ArchUnit 0.10.1

Bug Fixes

• JavaPackage.PackageVisitor and JavaPackage.ClassVisitor are now public instead of package-private to be usable as public API

ArchUnit 0.10.0

Breaking Changes

• The deprecated method String JavaClass.getPackage() was replaced by JavaPackage JavaClass.getPackage(). To query the package name, please use String JavaClass.getPackageName().
• The deprecated method JavaClass.getDirectDependencies() has been removed -> use JavaClass.getDirectDependenciesFromSelf() instead
• The deprecated field JavaClass.Functions.SIMPLE_NAME has been removed, please use JavaClass.Functions.GET_SIMPLE_NAME

New Deprecation

• ArchUnit does not use contractions anymore within the rules API. So far many methods were phrased like dontHave...() instead of doNotHave...(). In general this seems to be more trouble than worth it and does not read that well without an apostrophe, so all those methods were declared deprecated and have a new counter part without the contraction. A simple search & replace of dont by doNot should fix all those deprecations.
• Some methods were deprecated because they were not precise enough, if generics come into play. For example JavaClass JavaField.getType() is not precise enough, because the type of a field is something else than a JavaClass (like T someField or List<? extends T> someField). Thus all those methods have been deprecated to make room for a future extension with generics and instead got a new version explicitly stating that the "raw type" is meant. For example JavaField.getType() -> JavaField.getRawType(), JavaMethod.getParameters() -> JavaMethod.getRawParameterTypes().
• Formatters.formatLocation(JavaClass, lineNumber) was deprecated in favor of the newly introduced SourceCodeLocation.of(JavaClass, lineNumber) which will report the correct location (i.e. link for IDEs) via toString()

Enhancements

Core

• The default class resolution behavior for classes missing from the import was changed. Before by default missing classes were replaced by stubs, now by default they will be resolved from the classpath. Compare the user guide (see #111)
• JavaClass can now be queried for declared throws clauses, any Throwables declared on methods or constructors count as dependencies of a JavaClass (see #126; thanks a lot to @tngwoerleij)
• JavaClass can now be queried if it is an array (see #114; thanks a lot to @wengertj)
• The resolution of classes from the classpath will now use the context ClassLoader if set (should usually not make any difference, but allows to control the ClassLoader used by ArchUnit for class resolution)
• JavaClass now has a more sophisticated JavaPackage attached to it. It is also possible to retrieve any JavaPackage from JavaClasses. JavaPackage offers a more convenient API for dependencies between packages (see #158; thanks a lot to @goetzd for reviewing and user guide adjustment)
• For arrays JavaClass.getPackageName() now returns the package of the component type instead of empty. While empty is closer to the Java Reflection API, it is not really useful from a point of view of dependencies. Using an array of a type in a package should cause a dependency to that package (see #161)

Lang

• The rules API now provides an extensive support for checks of members / methods / fields (see #38; thanks a lot to @hankem for an extensive review and many improvements)

Library

• It is now possible to create a CompositeArchRule from several ArchRules to check multiple rules at once (see #78; thanks a lot to @bogsi17)
• The PlantUML rules API now understands more types of arrows (description on arrows, arrows from right to left, arrow colors), compare the user guide (see #135)
• New predefined rule to avoid the use of org.joda.time in favor of the java.time API (see #145; thanks a lot to @sullis)
• The slices API is now more configurable to deal with inconsistent package structures and legacy projects. It is now possible to customize the assignment of JavaClasses to Slices by a simple function JavaClass -> Identifier, compare the user guide (see #156)

JUnit

• The JUnit 5 platform dependency has been upgraded to version 1.4.0.

Further Acknowledgement

• Thanks a lot to @alanktwong for improving the CONTRIBUTING docs on how to build the project
• Thanks a lot to @wengertj for removing use of deprecated Gradle API
• Thanks a lot to @olleolleolle for replacing the PNG build badge by SVG
• Thanks a lot to @sullis for updating the Travis build to use OpenJDK 11

ArchUnit 0.9.3

Bug Fixes

Fixed memory leak in combination of the newly added ArchRule.AssertionError and JUnit 4. JUnit 4 keeps references to all thrown AssertionErrors through the whole run. Since ArchRule.AssertionError kept a reference to EvaluationResult this could consume a lot of memory, if the respective results were big.
This release removes ArchRule.AssertionError (introduced in version 0.9.0).

Note that this is in theory a breaking change, since it would have been possible to catch and process ArchRule.AssertionError. There does not seem to be any clean solution to this problem though, and due to the slim probability that the removal of this part of the API will in fact affect any user, the step seems justified.

If anybody should against all odds have a problem with this, feel free to open an issue and we will find a different solution.

Also ArchUnitTestEngine's engine id has been adjusted from junit-archunit to archunit to get rid of the warning JUnit 5 emits since version 1.3.0.

ArchUnit 0.9.2

Enhancements

• Added Java 11 support (see #117; thanks a lot to @hankem)
• ArchUnitTestEngine's UniqueId is now archunit instead of junit-archunit to make it clear that it is not maintained by the JUnit 5 team

ArchUnit 0.9.1

Bug Fixes

• Fixed a bug where classes in Jars with white spaces (like Kotlin class files could have) cause an exception during the import (see #103)

ArchUnit 0.9.0

Important

The Maven coordinates for com.tngtech.archunit:archunit-junit have changed, since there is now support for JUnit 4 and JUnit 5. The new coordinates for the equivalent artifact are now

com.tngtech.archunit:archunit-junit4:0.9.0

Enhancements

Core

• archunit-ignore-patterns.txt can now contain comments (see #88; many thanks to @bedla)

• a JavaClass' directDependenciesFromSelf and directDependenciesToSelf now contain further dependencies. This affects many rules as well, like layeredArchitecture() which might now detect more violations than before. In particular dependencies now contain dependencies from

  • fields of a certain type
  • method/constructor parameters of a certain type
  • method return types

  (see #92 and #96; many thanks to @msherman32)

• the plugin mechanism activating Java >= 9 support now supports EA versions (see #93; many thanks to @jqno)

Lang

• the rule API now supports a concise way to assert properties of a single class (see #60; many thanks to @msherman32)
• the rule API can now assert that classes haveOnlyFinalFields() (see #86; many thanks to @bgalek)
• the rule API now allows to assert that there are at least / at most / exactly x classes matched by a rule (see #83; many thanks to @bedla)
• rules can now be derived from PlantUML component diagrams (compare the User Guide; see #4; many thanks to @msherman32)
• the rule API now allows to check more general for dependencies instead of just accesses (like interfaces, field types, method parameters, ...) (see #69)
• the rule API now includes several methods to restrict what classes should "only" do, i.e. classes().should().onlyDependOnClassesThat()... or onlyCallMethodsThat(..), etc. (see #84)

JUnit

• ArchUnit now offers extended JUnit 5 support (compare the User Guide; see #34)

Kotlin

• rule suits with JUnit 4 / JUnit 5 can now be written in a concise way and source locations are reported correctly (compare the User Guide; see #77)

ArchUnit 0.8.3

Bug Fixes

Fixed bug where deeply nested super classes missing from the import were not resolved correctly from the classpath (see #91; many thanks to @svenackermann for reporting and debugging)

ArchUnit 0.8.2

Bug Fixes

Fixed a bug where the classpath property could not be parsed on Windows when using Eclipse Neon. Former versions of ArchUnit assumed all entries would be of the form C:\some\path (which seems to be the case for most IDEs/build tools), now also entries of the form /C:/some/path can be processed (see #79)

ArchUnit 0.8.1

Bug Fixes

• Fixed a bug where classes in Jars would not be imported on Windows, if Java version >= 9 and the whole classpath is imported; this only affects an import of the whole classpath with Jars, it does not affect importPackages(..), importPaths(..) or importJars(..) (see #73)

Enhancements

• When specifying a layeredArchitecture(), referring to a missing layer within onlyBeAccessedBy(..) will now throw an exception with a better error message (see #74)