-
-
Notifications
You must be signed in to change notification settings - Fork 260
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
Developing in eclipse becomes a pain #2653
Comments
Well, there are no compile errors when I set that to true and do
We can look closely at how TLDR: Example steps:
What we see is that the compilation command line args used by maven-compiler-plugin is not different. More specifically for us we especialy looking at the compilation args used to compile command line options for compiling
|
Note that I also saw these compile errors. What Eclipse IDE compile seemed to want is some of the maven That is, maven (and IntelliJ) were happy with these test scope dependencies staying as test scope with no explicit mention in module-info and yet Eclipse IDE compile needed these to be in module-path (incorrectly). What I think maven tooling is doing wrt tests is approximately "creating a new unnamed module that 'patches in' everything from |
Thanks for your feedback. It seems that there is currently no solution/workaround for eclipse As I understand this bug report While having a Options that I see now:
|
Hmmm. I don't know exactly what the eclipse compiler is doing, it would be good to know for sure ... I wonder if there is any way to find out. |
I am currently debugging this. What I've found out till now
I did not yet figure out, what happens here exactly |
Hello @rbygrave, after spending some time of debugging the eclipse compiler, I give up to fix this problem in eclipse. How to reproduce:
Is it correct/neccessary to check that option or do we miss something? Output of working test
Output of failing test:
|
Ah yes. I use that and in fact I have modified IntelliJ junit to default to having this option ... sorry, I kind of forgot that. Noting that this means that running tests in IntelliJ is then similar to maven surefire which is configured to use classpath via |
I see that you've added some documentation here |
Ok cool - closing. |
Also grabbing your other comment @rPraml to put it in here: @rbygrave FYI: This bug is reported here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=577790 We currently use the eclipse compiler (ecj) in nearly all of our projects as it supports multi-threading and is almost twice as fast as javac. And it behaves exactly the same as in eclipse. (There are some code places, where the javac expects excplicit casts, while ecj does not) We do not use JPMS, yet, but we intend to use it. We are also seriously considering moving from Eclipse/Ecj to IntelliJ/Javac due to the issues I've seen over the past few weeks... |
EDIT Oh I didn't see the multi-module release issue... I wonder why have not stumbled on to that. FWIW as I use Eclipse and there are some projects where this is an issue but it isn't really Eclipses fault. There is no effective way to merge modules and I'm not quite sure what Maven does for The easiest solution is to isolate your code that has issues and just generate the Or if this is just a unit test issue do blackbox testing. Besides Other than that I actually think Eclipse's support for modules is sometimes better than Intellij (I'm not sure why but Intellij doesn't seem to narrow the ctrl+space search to just module selection for me). |
First of all: This is not really an ebean issue, but maybe I can get some tips here, how to proceed.
We are using eclipse. Unfortunately with Ebean 13, the code base becomes incompatibe with eclipse
I think the main reason is JPMS / bad JPMS support in eclipse (and maybe also my lack of knowledge about JPMS)
Expected behavior
Actual behavior
--add-exports org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
and
--add-exports org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
) I found that tip here https://www.edvpfau.de/junit5-debugging-mit-eclipse-und-gradle/Steps to reproduce
Checkout current master and import it in eclipse (Version 2022-03)
Note
Currently I run the tests in maven, but this makes it harder to debug (and it costs also more time)
I also noticed, that I get similar errors if I enable
surefire.useModulePath
in the POM file.(Unfortunately I did not find this option in eclipse)
The text was updated successfully, but these errors were encountered: