Skip to content

Optionally ban JUnit 4 imports #1178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
timja merged 6 commits into from
Aug 15, 2025
Merged

Optionally ban JUnit 4 imports #1178

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
260826a
Optionally ban JUnit 4 imports
daniel-beck Aug 13, 2025
3d7cb1c
Add tests
daniel-beck Aug 15, 2025
1f2fe33
Add documentation
daniel-beck Aug 15, 2025
ae29578
Fix typo in file path
daniel-beck Aug 15, 2025
a1fef44
Fix another typo in file path
daniel-beck Aug 15, 2025
57ab9f3
Grammar
daniel-beck Aug 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -151,6 +151,9 @@
<!-- Set to false to enable Spotless -->
<spotless.check.skip>true</spotless.check.skip>

<!-- Set to false to enable enforcer banning org.junit.* imports -->
<ban-junit4-imports.skip>true</ban-junit4-imports.skip>

<!-- Whether to skip tests during release phase (they are executed in the prepare phase). -->
<release.skipTests>true</release.skipTests>
<!-- By default we do not create *-tests.jar. Set to false to allow other plugins to depend on test utilities in yours, using <classifier>tests</classifier>. -->
Expand Down Expand Up @@ -533,6 +536,11 @@
<artifactId>extra-enforcer-rules</artifactId>
<version>1.9.0</version>
</dependency>
<dependency>
<groupId>de.skuzzle.enforcer</groupId>
<artifactId>restrict-imports-enforcer-rule</artifactId>
<version>2.6.1</version>
</dependency>
</dependencies>
<executions>
<execution>
Expand Down Expand Up @@ -658,6 +666,23 @@
</rules>
</configuration>
</execution>
<execution>
<id>check-junit-imports</id>
<goals>
<goal>enforce</goal>
</goals>
<phase>process-sources</phase>
<configuration>
<rules>
<RestrictImports>
<reason>Use JUnit 5 (org.junit.jupiter.*)</reason>
<bannedImport>org.junit.**</bannedImport>
<allowedImport>org.junit.jupiter.**</allowedImport>
</RestrictImports>
</rules>
<skip>${ban-junit4-imports.skip}</skip>
Comment on lines +676 to +683
Copy link
Member

@jtnord jtnord Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we doing this at the source level and not banning the dep?

This means that IDEs will happily suggest junit4 etc in auto completion and tests in IDEs will pass (but the build will fail from the CLI).
Banning the dependencies directly in a profile activated by the property would seem to solve the issue by having compilation fail would it not?
@daniel-beck was there a reason that banning the dependency was not done rather than just banning the import?

Copy link
Member

@jtnord jtnord Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we doing this at the source level and not banning the dep?

This means that IDEs will happily suggest junit4 etc in auto completion and tests in IDEs will pass (but the build will fail from the CLI). Banning the dependencies directly in a profile activated by the property would seem to solve the issue by having compilation fail would it not? @daniel-beck was there a reason that banning the dependency was not done rather than just banning the import?

Yes it is harder to apply as this (IIRC) need to go in the .mvn/maven.config rather than just a pom property, but we do that for CD releases so its nothing new per say

Copy link
Member Author

@daniel-beck daniel-beck Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was there a reason that banning the dependency was not done rather than just banning the import?

I did not consider that option.

Copy link
Member

@froque froque Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we doing this at the source level and not banning the dep?

would that work with dependencies that depend on junit 4 ?

I am thinking of this long standing testcontainers issue as an example testcontainers/testcontainers-java#970

Copy link
Member

@jtnord jtnord Aug 18, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you would need to add exclusions on the dependency that brough junit4 in.

This would be almost every plugin due to https://github.com/jenkinsci/jenkins-test-harness/blob/0c38b4e6bcfa401dc675f39ce8112b839150cc75/pom.xml#L134-L137 but then that would serve as a reminder that perhaps some other things still need to happen first.

But I am not fully sure what you are asking - maven's invocation via surefire of things is platform aware so anything pure junit5 should work without exception (how gradle handles test engines is unknown to me).
And if it is not pure junit-5 then you would not opt in to the ban.

</configuration>
</execution>
</executions>
</plugin>
<plugin>
Expand Down