Odd behaviour of debugger: jumping into .class file instead of .java

In fact, this is not limited to the debugger
I have an interface X in a package of some module
in another package of the same module, I have a class which implements X.

But going from X to the source of the implementing class seems impossible... It always jumps to the compiled version... how strange...

How can I debug this?

I think it is all about project configuration. Do not add jarred version of Z as a library to Y. Let Y depend on Z like it really
is.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Frederic Donckels" <no_mail@jetbrains.com> wrote in message news:13116935.1121257822009.JavaMail.javamailuser@localhost...

Project X has modules Y,Z

>

Module Y depends on a jarred version of Z

>

Now, I have a test case for a class WW belonging to Z, and the test case is in Z too. When I debug the test case, I put a
breakpoint just before a method call on WW. At that point, if I:
- CTRL-B : IDEA jumps into the source code
- F7 (step into): IDEA jumps into the compiled WW.class which, apparently, it finds in the jarred Z that Y has in its libraries.

>

Isn't that odd? Why does it even search outside module Z? Both WW and TestWW are in the same module, there is no reason to search
outside... What could cause this? Any idea how I could solve this?

I had a similar problem. There are several parent projects, each with many child projects.  When I ran the debugger for a test in one child project, that depended on code in a separate parent project, I had to make sure that the pom version referenced in the child project matched the pom version in the separate parent project.  Also, I did "Reload All Maven Projects" in the Maven view.  When that finished, I did mvn clean install (with tests turned off) for all the parent projects, in order of dependency (ie: Y depends on X, build X first, then build Y).  With that completed, I ran the test again and now it was using the latest code when debugging.  The issue was that the pom for Y was pointing to a version of the parent project that was not set in the parent project pom, but rather was a non-snapshot older version.  So it was snagging a jar file with the outdated version.  When I pointed Y to the latest snapshot version in X, did the builds and did the reload maven projects, this fixed the dependency issue.