You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the screen shot herewithin you will see that the Dependencies tree shows two versions of the TestingSupport sub-project. Every peer sub-project under the root project shows-up twice.
On the file shown, LoopbackDrone class I can use as an example of strange things that happen with Netbeans and project dependencies.
the debugger is NOT finding breakpoints in valid code
Lots of spurious red-marks to indicate syntax errors in for code that compiles perfectly on both the command line and with a netbeans build
For example I am told "can not find symbol 'String'".
When using the debugger and a line breakpoint is actually showing as defined, the debugger ignores the breakpoint and does not stop.
I have checked with the debugger source and it looks to be using the correct file.
On a different occasion, I've had the debugger look at teh JAR file in the local maven repo for a build library JAR. That can be coped with because the debugger does still stop.
For what ever reason it is like that code for these files does not exist at runtime.
The logger output demonstrates that the LoopbackDrone class is working yet no breakpoints are triggered.
In this case the LoopbackDrone is used in a Spock unit test specification
Gradle or spock hide the log output someplace under the build/ folder
Once the test fails due to some exception or other that log output is sererly truncated
Is there some way to be able to "view" the log output while a is running?
tail won't work on the JUnit test logger output - We've tried everything.
These symptoms are not just on one file. From time to time such events can occure at odd times on any file from another dependency. Sometimes blowing away the Gradle caches and .gradle directory fixes things for about an hour or so.
In general that can be ignroed or worked past. On this lower-level task used on testing that's not the case since this is exercising a core part of my build and we need to ensure that it is working correctly. Which it isn't -- that's why I'm debugging it ;)
Hope someone can suggest a fix for this.
The text was updated successfully, but these errors were encountered:
Can I see your build scripts? My current guess is that somehow your intTest source set has the output of main twice in its dependencies but through different paths.
Unfortunately the duplication of dependencies pre-dates our use of this file. It happens in every project. It just wasn't seeming to be causing trouble unilt I wanted to debug that file I mentioned. Apart from loading src-jar files when I wanted to use the original.
I wonder if it is something with Gradle I saw this on Windows more than i see it on Linux. That was a major reason to dump Windows for development, I was wasting too much time chasing ghosts like this.
Hi I'm using Netbeans 8.2 with Gradle
O/S name: Linux
Gradle version: 4.10.3
Groovy version: 2.4.15
nb-Gradle-plugin: v1.4.4
In the screen shot herewithin you will see that the
Dependencies
tree shows two versions of theTestingSupport
sub-project. Every peer sub-project under the root project shows-up twice.On the file shown,
LoopbackDrone
class I can use as an example of strange things that happen with Netbeans and project dependencies.LoopbackDrone
class is working yet no breakpoints are triggered.LoopbackDrone
is used in a Spock unit test specificationbuild/
folderThese symptoms are not just on one file. From time to time such events can occure at odd times on any file from another dependency. Sometimes blowing away the Gradle caches and .gradle directory fixes things for about an hour or so.
In general that can be ignroed or worked past. On this lower-level task used on testing that's not the case since this is exercising a core part of my build and we need to ensure that it is working correctly. Which it isn't -- that's why I'm debugging it ;)
Hope someone can suggest a fix for this.
The text was updated successfully, but these errors were encountered: