Skip to content
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.

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

Upgrade to JUnit 5.2.0 #13118

Closed
sbrannen opened this issue May 9, 2018 · 27 comments

Comments

Projects
None yet
7 participants
@sbrannen
Copy link
Member

commented May 9, 2018

The JUnit 5 versions can be updated in spring-boot-dependencies.

  • junit-jupiter.version -> 5.2.0
  • junit-platform.version -> 1.2.0

Note: please keep the Platform version in sync with the Jupiter/Vintage versions. I only point that out, since that is not currently the case in spring-boot-dependencies.

In addition, I would recommend against tying the Vintage version to Jupiter. Although they are currently the same number, there is no guarantee that will always be true. Plus, I think it's just easier for people to consume if they see junit-vintage.version when dealing with the JUnit Vintage dependency. 😉

@vpavic

This comment has been minimized.

Copy link
Member

commented May 9, 2018

With upgrade to JUnit 5.2 Boot's dependency management should start using junit-bom which would automatically address the concerns @sbrannen expressed.

@wilkinsona wilkinsona added this to the Backlog milestone May 9, 2018

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 9, 2018

@vpavic, yep... great idea to profit from the new junit-bom!

Except that... well... the junit-bom doesn't yet contain properties for the versions. 😉

But that might be addressed soon: junit-team/junit5#1405

@wilkinsona

This comment has been minimized.

Copy link
Member

commented May 9, 2018

Having properties for the versions won't be of any benefit here. Properties can only be overridden when a bom is using as a parent. They're set in stone when a bom is imported (as we'd do in spring-boot-dependencies).

@wilkinsona

This comment has been minimized.

Copy link
Member

commented May 9, 2018

I've just read the referenced JUnit 5 issue and I'm pretty sure it won't help there either for the same reason.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 9, 2018

Ahhhhh....

💡 This sounds like a case of Mr. Brannen confusing the features of parent POMs and imported BOMs.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 9, 2018

So, would Spring Boot even want to import the junit-bom?

If I understood you correctly, wouldn't that make it less flexible for end users than declaring the JUnit dependencies manually as Boot does now?

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 9, 2018

I've just read the referenced JUnit 5 issue and I'm pretty sure it won't help there either for the same reason.

Thanks for investigating!

Quick question though: wouldn't having the versions defined as properties in the BOM still be useful for the case where a user wants to refer to the version of the JUnit Platform Maven Surefire provider artifact in the plugin management section (which is not imported from the BOM)?

Or is that a moot point in that the properties are not visible when imported?

(thinking I should go research the exact semantics of importing BOMs now 😉 )

@snicoll

This comment has been minimized.

Copy link
Member

commented May 9, 2018

properties are not visible when imported

They are not.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 9, 2018

Thanks, @snicoll!

I guess that makes it pretty clear. 🙇

@xmlking

This comment has been minimized.

@snicoll

This comment has been minimized.

Copy link
Member

commented May 14, 2018

@sbrannen I was looking at that bom again and I can see it mixes two versions. Will you consider merging those as a single version in the future? (IMO it's confusing the "junit bom" bring JUnit X.Y.Z and something else with a different version.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 14, 2018

Hi @snicoll,

No. We currently have no plans to change the major version of the JUnit Platform to match the version of either JUnit Jupiter or JUnit Vintage.

Since the JUnit Platform is an entirely new invention, we collectively decided to release it as version 1.0.

JUnit Jupiter and JUnit Vintage are technically new as well, but the team decided to release Jupiter as version 5.0 instead of 1.0 for purely marketing reasons, so to speak (i.e., because 5 logically follows 4).

And with regard to Vintage, we admittedly made a mistake by initially releasing it as 4.12.0, when should have released it as 1.0.0 as well. We were then forced to change it to 5.x since going back to 1.x after the JUnit Platform 4.12.x releases was no longer possible.

So, yes, it's a bit confusing, but I don't foresee the team changing the version of the Platform to align with Jupiter.

Hope that makes sense.

@snicoll

This comment has been minimized.

Copy link
Member

commented May 14, 2018

Thanks for the feedback. I am not sure I understand the rationale still (and this issue may not be the best place to discuss this). I should also share that this dual versioning confuses me.

From my point of view, as soon as you release a "JUnit bom" with a set of dependencies, I expect them to be your recommendation for that version of "JUnit". A side effect of that is that it shouldn't be recommended to take JUnit 5.2 with a different version of the JUnit platform (or the other way around).

I am asking because using the JUnit bom means that the junit-platform.version is going away as we have no way to influence that anymore.

If you agree all this makes sense, I'll go ahead and make that breaking change (Also, I don't think that using different versioning is warranted at that point).

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented May 14, 2018

I'm in a hurry to leave, so I'll have to get back to you with more details.

But just a quick question: how is the junit-bom any different than the spring-cloud-dependencies BOM with regard to harmonizing multiple dependencies with different versions?

@snicoll

This comment has been minimized.

Copy link
Member

commented May 14, 2018

how is the junit-bom any different than the spring-cloud-dependencies BOM with regard to harmonizing multiple dependencies with different versions?

Surface area? Spring Cloud has a concept of "release train" that brings naturally the concept of different things forming an umbrella. The same thing can't be said of JUnit IMO.

If you support the engine to be upgraded independently of the "Junit jupiter" version, then this change may be problematic. I just want to be sure we're aware of this before making it.

@wilkinsona

This comment has been minimized.

Copy link
Member

commented May 14, 2018

using the JUnit bom means that the junit-platform.version is going away

That would be bad while it's still necessary to set up Surefire like this:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<dependencies>
		<dependency>
			<groupId>org.junit.platform</groupId>
			<artifactId>junit-platform-surefire-provider</artifactId>
			<version>${junit-platform.version}</version>
		</dependency>
	</dependencies>
</plugin>

AIUI, Maven dependency management has no effect on plugin dependencies such as the dependency on org.junit.platform:junit-platform-surefire-provider shown above. If we drop our junit-platform.version property users will be left to figure out for themselves the right version of the Platform to use. Perhaps we should view that as a JUnit problem rather than a Spring Boot problem? It's caused by the JUnit team's decision to use different versions after all.

@sormuras

This comment has been minimized.

Copy link

commented May 14, 2018

using the JUnit bom means that the junit-platform.version is going away

That would be bad while it's still necessary to set up Surefire like this: [...]

Working on this issue... end of May. Is the plan.
https://issues.apache.org/jira/browse/SUREFIRE-1330

@snicoll

This comment has been minimized.

Copy link
Member

commented May 22, 2018

What @wilkinsona wrote.

I'm in a hurry to leave, so I'll have to get back to you with more details.

@sbrannen what is the reason for including the platform bits in the bom then? It's not going to be used as a dependency in user's app as far as I understand it and the mechanism by which it is being used in Maven at the moment makes that useless (as Andy already indicated).

My vote would be a unified version of course but, if those dependencies aren't targeted to the project's classpath, maybe they shouldn't be there at all?

@snicoll

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

ping @sormuras and @sbrannen

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2018

Working on this issue... end of May. Is the plan. https://issues.apache.org/jira/browse/SUREFIRE-1330

The last I heard from @sormuras on this topic is that the official support for the JUnit Platform may go into Maven Surefire by the end of this week.

@snicoll

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

@sbrannen thanks, the ping was actually related to the comment above the ping.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2018

Yes, I know.

I'm authoring a response to that in another tab.

Patience, my friend. 😉

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2018

what is the reason for including the platform bits in the bom then? It's not going to be used as a dependency in user's app as far as I understand it

JUnit 5 is an umbrella project. As stated in the User Guide: JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

Most people will only rely directly on an engine and its API (e.g., Jupiter, Spek, etc.).

However, there are certainly people who will depend directly on parts of the JUnit Platform -- for example, to author a custom TestExecutionListener, a custom TestEngine, etc., or to make use of the ConsoleLauncher, etc.

Thus, the JUnit BOM is in fact a release train for modules in the Platform, Jupiter, and Vintage that are known to work together.

If a given project only directly depends on the Jupiter API for writing tests and extensions (e.g., a test dependency in Maven or a testCompile dependency in Gradle), that's fine, but that project will still need the Platform's modules in order to actually run (e.g., the Launcher API, etc.).

With regard to the latter, it may well be that the IDE or build tool bundles versions of Platform modules by default. In fact, I think they all do that. But the user may be using a new version of the Platform than is bundled by default. Thus, the JUnit BOM ensures that users can pull in the latest and greatest parts of a particular release train into their build or IDE.

and the mechanism by which it is being used in Maven at the moment makes that useless (as Andy already indicated).

Yes, we are more than fully aware of that.

It has been a thorn in our side since day # 1.

That's why @sormuras is devoting so much of his personal time to ensure that the Maven Surefire project incorporates that support natively in the next Surefire release.

My vote would be a unified version of course

Although the JUnit team has, thus far, released all modules within a given release train simultaneously, this may not always be the case. It is perfectly reasonable to expect that the JUnit team will stop releasing the Vintage module and Platform modules with new versions if those modules contain zero changes. In other words, the Platform, Jupiter, and Vintage subprojects may some day live in separate GitHub repositories with separate release cycles.

but, if those dependencies aren't targeted to the project's classpath, maybe they shouldn't be there at all?

See above.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2018

If you support the engine to be upgraded independently of the "Junit jupiter" version, then this change may be problematic. I just want to be sure we're aware of this before making it.

I don't foresee the junit-jupiter-engine artifact ever being released under a different version than the junit-jupiter-api artifact. Those will likely always stay in sync.

But... the Platform modules may potentially be updated independently.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2018

But the user may be using a new version of the Platform than is bundled by default.

For a concrete example, consider the "Additional Gradle Dependencies" and "Additional Maven Dependencies" sections of the JUnit 5 User Guide that were added explicitly to assist users of IntelliJ IDEA.

@sormuras

This comment has been minimized.

Copy link

commented Jun 6, 2018

Jupiter API needs JUnit Platform Commons at compile time

End-users (read: @Test-method writers) will only refer to junit-jupiter-api, current version is: 5.2.0, at compile-time. A transitive dependency of junit-jupiter-api is junit-platform-commons (1.2.0 as of today). For details see https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api/5.2.0

At runtime, a matching version of junit-jupiter-engine is needed. 5.2.0 is a safe bet, could be 5.2.1 (or even 5.3). And of course all artifacts that make up a runnable platform. The default entry point is the DefaultLauncher residing in junit-platform-launcher: https://mvnrepository.com/artifact/org.junit.platform/junit-platform-launcher/1.2.0

So. Does having a BOM make sense at all for "JUnit"? I don't know. Never used it.

@sbrannen

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2018

So. Does having a BOM make sense at all for "JUnit"?

Yes, of course.

Some people will love it; others will dislike it (or simply will not benefit from it); but in the end it's optional. Nobody is forced to use a BOM.

@snicoll snicoll self-assigned this Jun 17, 2018

@snicoll snicoll modified the milestones: Backlog, 2.1.0.M1 Jun 18, 2018

@snicoll snicoll changed the title Upgrade to JUnit 5.2 Upgrade to JUnit 5.2.0 Jun 18, 2018

@snicoll snicoll closed this in fa7da40 Jun 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.