After an “empty” new Gradle project is created with Buildship, it creates, by default, a “LibraryTest” class that fails to build because JUnit 4 is not automatically added to the build path.
Error: “Test cannot be resolved to a type”
Here is the content of the unmodified build.gradle:
// Apply the java plugin to add support for Java
apply plugin: ‘java’
// In this section you declare where to find the dependencies of your project
repositories {
// Use ‘jcenter’ for resolving your dependencies.
// You can declare any Maven/Ivy/file repository here.
jcenter()
}
// In this section you declare the dependencies for your production and test code
dependencies {
// The production code uses the SLF4J logging API at compile time
compile ‘org.slf4j:slf4j-api:1.7.18’
// Declare the dependency for your favourite test framework you want to use in your tests.
// TestNG is also supported by the Gradle Test task. Just change the
// testCompile dependency to testCompile 'org.testng:testng:6.8.1' and add
// 'test.useTestNG()' to your build script.
testCompile 'junit:junit:4.12'
}
So JUnit shows up there, but nothing seems to get it to automatically add the dependency (Refresh, Project->Clean, …). I end up having to do the Quick Fixes to add JUnit manually and add the static import, but I expected this to be automatic.
Creating the new Java project from the wizard should work without any problems. Your problem seems a bit weird though as the quick fix can refactor the code to use the static imports. Which operating system do you use? Also, does you project have a similar structure than on the screenshot?
Also make sure there are no dependency resolution errors in the console log. You might be behind a proxy that does not allow fetching artifacts from jcenter().
Thanks, Donat and Stefan. I’m using Windows 7. I believe Stefan is
right. Although I configured my Eclipse proxy settings earlier and got
rid of obvious errors, apparently it’s still failing to
download/configure everything properly. I then tried on my laptop (Win
10) on a guest network here, and it worked fine.
I was able to reproduce the problem from scratch on the secure network,
and now see the “Could not resolve” output in the Console. Sorry, missed
that.
I believe you must be writing those resolution failures to stdout,
correct? I’d suggest that you write them to stderr instead, as they’ll
show up clearly in red. The resolution failures are also easy to miss
also because surrounding them are all “BUILD SUCCESSFUL” messages – not
sure how it considers these to be successes.
Thanks for your help, and keep up the great work!
Ari
Thanks, Stefan. I still don’t understand how the build is considered
successful, though. It fails to compile because of the missing
dependencies. How could it be successful?
Ari
That message is the “build” that fetches the Eclipse model. It did not actually build your Java sources. There has been some discussion whether we should remove this output completely. I personally find it confusing, but on the other hand it is currently the only place where you would see stuff like the unresolved dependency message I told you about.
Yeah, it’s definitely misleading. If it really only refers to ‘the
"build" that fetches the Eclipse model’, then it should be a completely
different info message. Everyone accustomed to build tools assumes that
"BUILD SUCCESSFUL" means everything compiled and processed fine.
