-
Notifications
You must be signed in to change notification settings - Fork 306
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make ArchUnit JUnit 5 support Java Modules compatible #827
So far, even though we added `Automatic-Module-Name` to the `MANIFEST` to make it compatible with Java Modules, ArchUnit's JUnit 5 support could not be used on the modulepath. The reason is that all three modules `archunit-junit5-api`, `archunit-junit5-engine` and `archunit-junit5-engine-api` export the same package `com.tngtech.archunit.junit`. We now fix this by splitting the three modules into separate packages. This is a little tricky since there is also code that is shared with ArchUnit JUnit 4 support and we want to keep as many internals package private as possible. I tried to find a good compromise between backwards compatibility and public surface, the result is * API stays the same, i.e. toplevel `c.t.archunit.junit` * Engine and shared internal infrastructure are moved to `c.t.archunit.junit.internal` (this causes no problem, because engine dependencies were always only transparent runtime dependencies via `ServiceLoader`, never compile time dependencies) * Engine-API is moved to `c.t.archunit.junit.engine_api`. This is a breaking change, however the `engine-api` is a very specific artifact that is only needed for frameworks to integrate with JUnit Platform. So it should only affect a very limited number of users. Unfortunately the JUnit 4 design makes it very hard to cleanly split API and implementation. I.e. by making the `Runner` type public API (having to explicitly declare it as `@RunWith(..)`) tends to cause a chain reaction pulling more and more into the public scope. In particular if now the classes that are used internally (like `ClassCache`) don't reside in the same package anymore. I tried to find some compromise by creating an internal delegate that is loaded via Reflection. This way we can keep the things inside of `internal` conceiled with package-private scope. Hopefully this will not cause any problem in the long term. Note that it will still not possible to put both JUnit 4 and JUnit 5 support on the modulepath together, but I also don't see any reason why anybody should want to do this, since they serve exactly the same purpose and JUnit 5 support is just more future proof. Resolves: #206
- Loading branch information
Showing
78 changed files
with
696 additions
and
498 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.