Skip to content

Conversation

@trancexpress
Copy link
Contributor

Fixes: #436

@trancexpress
Copy link
Contributor Author

I wonder if we should mention the potential conflicts between JUnit 5 and JUnit 6 in the PDE 4.38 N&N entry? Since Eclipse 4.38 will contain both versions and likely plug-in maintainers will run into the issue of mixed versions (that is at least so far not self-explanatory)...

@iloveeclipse ?

@trancexpress trancexpress requested a review from merks November 12, 2025 15:13
@iloveeclipse
Copy link
Member

I wonder if we should mention the potential conflicts between JUnit 5 and JUnit 6 in the PDE 4.38 N&N entry?

Yes, we should. Ideally with some hints how to find & resolve the "wrong" dependencies issue.

@trancexpress trancexpress force-pushed the gh436 branch 2 times, most recently from adf250b to dc948c7 Compare November 12, 2025 16:29
---
## JUnit Plug-in Test Launch

### JUnit 5 and JUnit 6 conflicts in Eclipse 4.38+
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@HannesWell @laeubi corrections/proposals for the text here are very welcome.


#### Add JUnit 6 library to the build path:

The JUnit Test Case wizard offers to add it while creating a new JUnit Jupiter test:
Copy link
Member

Choose a reason for hiding this comment

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

While reading this I wonder if we should propose this for projects configured for Java < 17? Also here we should mention, that JUnit 6 only works with Java >= 17.

Copy link
Contributor Author

@trancexpress trancexpress Nov 12, 2025

Choose a reason for hiding this comment

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

We could do this, see org.eclipse.jdt.internal.junit.ui.JUnitClasspathFixProcessor.getFixImportProposals(IJavaProject, String) which takes the project...

It would take some effort though, determining the classpath JRE version... Considering the user can define whatever they want.

Are you sure we should invest time in this? E.g. JUnit 5 allegedly requires Java 8, but there is no check for that.

We could make it low effort, I guess? Look for JavaSE-N container, evaluate N? But I'm not sure its worth the trouble. Especially considering we don't do such checks anywhere else where JUnit 6 is involved.

Copy link
Member

@iloveeclipse iloveeclipse left a comment

Choose a reason for hiding this comment

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

Let's merge to spread the news about it.
We can/will improve that anyway.

@iloveeclipse iloveeclipse merged commit d82fdd6 into eclipse-platform:master Nov 14, 2025
1 check passed
@merks
Copy link
Contributor

merks commented Nov 14, 2025

Yes, sorry. Too much to do and too much to track. Toward the end of the release, I generally sweep through all the N&N and tweak/improve a few things here and there and to make sure they looks relatively uniform.

Thanks for the additional content!

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.

N&N entry for JUnit 6 support

4 participants