Skip to content

Load junit-extensions for surefire tests - #394

Open
findepi wants to merge 2 commits into
airlift:masterfrom
findepi:findepi/load-junit-extensions-for-surefire-tests-1e1302
Open

findepi wants to merge 2 commits into
airlift:masterfrom
findepi:findepi/load-junit-extensions-for-surefire-tests-1e1302

Conversation

@findepi

@findepi findepi commented Feb 5, 2024

Copy link
Copy Markdown
Contributor

It is very useful when running JUnit tests, and harmless otherwise.

@findepi
findepi force-pushed the findepi/load-junit-extensions-for-surefire-tests-1e1302 branch 2 times, most recently from 723b4cd to 64b8279 Compare February 6, 2024 09:09
It is very useful when running JUnit tests, and harmless otherwise.
JUnit 5.10.1 has this somewhat desired feature of not ignoring
overridden tests. This is important behavioral aspect changed back in
5.10.2. Worth updating if only to prevent becoming used to 5.10.1
behavior.
@findepi
findepi force-pushed the findepi/load-junit-extensions-for-surefire-tests-1e1302 branch from 64b8279 to a23bfd8 Compare February 6, 2024 09:18
Comment thread airbase/pom.xml
Comment on lines +866 to +879
<additionalClasspathDependencies>
<additionalClasspathDependency>
<groupId>io.airlift</groupId>
<artifactId>junit-extensions</artifactId>
<version>3</version>
<exclusions>
<!-- additionalClasspathDependencies does not support dependency resolution, so dependencies result in duplicate/conflicting classpath elements -->
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</additionalClasspathDependency>
</additionalClasspathDependencies>

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

surefire's additionalClasspathDependencies appends requested maven artifact along with all its dependencies onto the test classpath. It does not do any dependency management / conflict resolution, it only prints a warning about conflicting dependencies. As a result, some maven artifacts can be duplicated, and some can exist in copies differing in version.

Exclusions disables this, of course. For exclusions to work, however, junit-extensions needs not to have dependencies. Currently it depends on log-manager for InitializeLogging extension. findepi/airlift-junit-extensions#1 makes this dependency optional and is required for this PR.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

That would be nice, but not by introducing complexity in junit-extensions. Why does additionalClasspathDependencies not do dependency management? Bug or feature? Maybe raise an issue with the maven project, or check it it's in Maven 4?

makes this dependency optional and is required for this PR.

This is problematic. In the future, there may be other dependencies. We can't make each and every one of them optional.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Why does additionalClasspathDependencies not do dependency management? Bug or feature?

it's documented, so i believe it's by design

https://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html
Since version 3.2.0 the additionalClasspathDependencies parameter can be used to add arbitrary dependencies to your test execution classpath via their regular Maven coordinates. Those are resolved from the repository like regular Maven project dependencies and afterwards added as additional classpath elements to the end of the classpath, so you cannot use these to override project dependencies or resources (except those which are filtered with classpathDependencyExclude). All artifacts of scope compile and runtime scope from the dependency tree rooted in the given dependency are added. The parametrization works like for regular Maven dependencies in a POM. Exlusions are supported as well. Neither the dependency management section from the underlying POM is used nor are the conflicts among the different dependency trees (from the project dependencies or from the additional dependencies) automatically resolved. Conflicts lead to warnings, though, which help you clean up the classpath manually. Only external dependencies (outside the current Maven reactor) are supported.

there may be other dependencies. We can't make each and every one of them optional.

Why can't we?
there is concrete value in junit-extensions being dependency-free, so that it can be very easily pulled into every module/project testing with junit. of course, it adds more burden on junit-extensions itself (eg need to enable features dynamically), but it may be worth it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Did i manage to clarify anything here?

@hashhar

hashhar commented Feb 23, 2024

Copy link
Copy Markdown
Contributor

cc: @ksobolew

@wendigo

wendigo commented Dec 1, 2025

Copy link
Copy Markdown
Contributor

Do we still need this or can I close it? @findepi

@findepi

findepi commented Dec 2, 2025

Copy link
Copy Markdown
Contributor Author

i still don't mind this being merged. Do you think it shouldn't? If so, I can close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants