Would running a unit test in Eclipse respect classpath exclusions?

I’m asking about something that I haven’t tried. I noticed a small limitation of Maven-based projects in Eclipse, and I was wondering if Gradle projects with Buildship would have the same issue. I won’t feel any less for Buildship if it does :slight_smile: , but it would be good to know if this works better in Gradle/Buildship.

If I have a Maven project with both unit tests and PaxExam integration tests, when I run a unit test it will have the PaxExam dependencies in the classpath. For me, this doesn’t cause things to break, but there’s a minor annoyance with configuring debug levels, in that it ends up consulting a pax artifact to determine whether debug logging is enabled, even though I’m not using pax in the test.

I can configure Maven Surefire to exclude those dependencies, so that when the Maven build runs, it doesn’t get confused about logging levels, but Eclipse m2e doesn’t have this level of integration, so running the unit test in eclipse still has pax artifacts in the classpath, resulting in annoying logging.

In a Buildship project, would “Run As Unit Test” in Eclipse have more intelligence, assuming my build.gradle had logic to ensure that unit tests only have unit test dependencies?

No, Buildship doesn’t separate dependency scopes at runtime. In fact, the classpath for each Buildship project is a union of all dependency scopes. We know this is suboptimal, but we will do some investigation how to improve this in the near future, so stay tuned.

@David_Karr There’s a Run as Gradle Test feature in Buildship that might be useful to this story. Just select a class or method in Eclipse (in the source editor, in the package explorer, or in the outline view), and from the context menu choose Run As.. > Run as Gradle Test. This will invoke Gradle directly to execute your test and therefore will have the correct classpath.

You can also re-execute tests. To do that, just find the node representing your test class/method in the Executions view, and from its context menu execute the relaunch.

@donat We are facing a similar problem as our multi project spring based project is heavily based on classpath scanning and mixing beans from other projects’ test sources makes a lot of unwanted side effects.

It kind of works with the “Run as > Gradle Test” approach.
Unfortunately it looks like runs always everything and it feels like there is a lot happening in the UI thread so the whole eclipse ui gets a bit unresponsive. Also it would be great to make this as “Debug as” option available

@Max_Bruchmann The UI responsiveness is fixed in the upcoming 2.1.0 release. If you have some time, please install the latest snapshot and give it a try, we’d appreciate the feedback.

The debugging feature is one of the many things we want to add to Buildship. Please give your :thumbsup: to the related issue so that we can prioritize the implementation.

Hi,
just tried the:
Buildship: Eclipse Plug-ins for Gradle 2.1.0.v20170629-2316-s org.eclipse.buildship.feature.group Eclipse Buildship

But it looks like the UI issue is still there using Neon.2 Release (4.6.2)

As for my problem with the united classpath I moved all test sources into separate projects which works but of course is not the ideal solution

Can you give us some more info on what UI issue exactly you are seeing? Maybe a little screencast?

Hi @st_oehme for some reason I cannot reproduce it anymore, maybe there was something stuck on eclipse side. Sorry for the false alarm

I let you know if it happens again