jmkao
commented
8 years ago Yes, that's true. I think the main benefit, which doesn't really come from BuildShip, is that the classpath of Eclipse's native build-test-run is synced with the classpath from Gradle.
BuildShip provides prettier visibility into the execution of gradle tasks, but doesn't yet seem to do much integration into the Eclipse native build/test/run/debug which does iterate much faster than with a gradle build.
WesGilster
Swagger is looking great. Since I closed the PR for the swagger stuff I figured I'd post this here. The run task is good because I can test true build paths instead of Eclipse build paths, that's why I kept believing the URL download was working when it was a build problem all along. The testing task isn't really that helpful outside of the fact that you allowed us to run tests as a prereq to build.
However, when it comes to Eclipse integration there are just too many efficiencies you loose with the Gradle run task like all forms of debugging, hot code replace, incremental compiling, thread management and profiling. The test task has the same integration drawbacks as the run task plus the missing junit integration points like single execution of a specific test, captured stack traces, redirected junit view output.
I could attach the debugger to a remote JVM as I do the Raspberry Pi, but that's when things get really contrived, because I start to wait 2 minutes for a Gradle build just so that I can attach a remote JVM. Way too much loss of productivity there.
None of this matters too much, since I think it would be easy for me to create the launchers. I just wanted to bring it up in the event I'm missing BuildShip's integration with Eclipse's execution/debugging environment.