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
Update Jupiter for Eclipse 09-23 #744
base: main
Are you sure you want to change the base?
Conversation
maho7791
commented
Nov 6, 2023
- Updated Junit Jupiter to work with Eclipse 09-23 IDE
- use bnd 7.0.0 to build
- Updated Junit Jupiter to work with Eclipse 09-23 IDE - use bnd 7.0.0 to build Signed-off-by: Mark Hoffmann <m.hoffmann@data-in-motion.biz>
Signed-off-by: Mark Hoffmann <m.hoffmann@data-in-motion.biz>
Hey @maho7791 , thanks for the PR! What's the end goal here, if you don't mind me asking? I'm surprised that osgi-test doesn't already work with Eclipse 09-23? |
The latest JUnit Laucher in the PDE 09-23 expects Jupiter 5.10. to work. If OSGi Test uses a dependency lower than 5.10 you end up MethodNotFound exceptio. This PR is just for completeness, so that OSGi Test also works with 5.10. |
If it's not too difficult, can you put the stack trace of that exception in here somewhere for posterity?
I think that the problem is not that OSGi Test won't work with 5.10 - I think it will as the JUnit team are pretty good about maintaining backward compatibility. The problem seems to be that the Eclipse 09-23's JUnit integration requires JUnit Platform >=1.10. So you can't run the tests inside the IDE. I'm guessing that they probably still work from Maven command line though,
I am not against increasing the baseline version that we compile against if there is a specific need for a newer feature in the newer version. However, in the absence of such a need I am hesitant. So if changing the runtime version fixes your problem with the IDE integration, perhaps we should stick with that for this PR. We can always revisit bumping up the compile version at some point if/when there is a case to be made to use a newer feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this!
Given that the second commit simply undoes one of the changes in the first commit, can we also squash these two into a single commit before merging?
@@ -29,7 +29,7 @@ | |||
<version>${revision}</version> | |||
|
|||
<properties> | |||
<revision>1.3.0-SNAPSHOT</revision> | |||
<revision>1.4.0-SNAPSHOT</revision> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.3.0 has not been released yet, so there is no need to bump this to 1.4.0.