Access restrictions on SpringJUnit4ClassRunner class

[jgaines]

When I try to annotate an integration test class with @RunWith(SpringJUnit4ClassRunner.class), I get an access rule error in Eclipse.

I'm obtaining the org.springframework.test-2.5.6.SEC01 bundle by expressing an optional dependency on it in template.mf and letting the Bundlor classpath container resolve it for me.

Drilling down through the build path/bundle classpath container to that bundle, I can see the access rule that only org.springframework.test.* should be accessible.

1. Where does this access rule come from, and what is its purpose?

2. I can work around this by lowering the severity level of access restriction rules in Eclipse. Is that reasonable?

3. Is putting the dependency in the manifest the best way to get access to that test package? The greenpages sample seems to do it via a maven dependency, but what if you don't use maven? I could also do it by including a hard copy of the test jar, but I'd like to be able to get the latest version from the enterprise repo; or by creating a local library and matching Eclipse variable, but I'd like the other developers to be able to check out the project and get moving without having to do a bunch of pre-setup on their workstations.

Thanks!

[jgaines]

In the manifest I was importing org.springframework.test. This pulled the jar onto the classpath, which made all its classes visible in Eclipse. But because I was only importing that package, and not org.springframework.test.context.junit4, I wasn't supposed to be able to see the SpringJUnit4ClassRunner. Eclipse reports this as an access restriction error, rather than a class not found exception or no class def error.

So the solution was simple - just import the specific, correct packages. (I should add that I started the project with automated manifest generation, but turned that off after a while as I was finding it difficult to understand the changes it was making. If I'd left it on, presumably it would have imported the correct packages for me). And leave the Eclipse preference for treating access restrictions as errors alone.

The one thing I'm still not sure about, though, is whether putting the test dependencies into the manifest with optional resolution is the smartest way to express them. If we used Maven, I could put 'em in the pom - but we don't.

What is the Best Way to capture test-only dependencies in an STS project?

[jgaines]

My original question related to Eclipse behaviour. Through my own stumbling around and RTFM'ing I was able to sort that out.

In my mind however the topic is metastasizing into the issue of best practice for testing Spring DM Server apps. I'll start a new thread in the app development forum for this.

[Andy Wilkinson]

In the manifest I was importing org.springframework.test. This pulled the jar onto the classpath, which made all its classes visible in Eclipse. But because I was only importing that package, and not org.springframework.test.context.junit4, I wasn't supposed to be able to see the SpringJUnit4ClassRunner. Eclipse reports this as an access restriction error, rather than a class not found exception or no class def error.

So the solution was simple - just import the specific, correct packages. (I should add that I started the project with automated manifest generation, but turned that off after a while as I was finding it difficult to understand the changes it was making. If I'd left it on, presumably it would have imported the correct packages for me). And leave the Eclipse preference for treating access restrictions as errors alone.

Yeah, that's exactly right. Glad to see that you got to the bottom of it. Apologies for not responding earler and saving you the trouble.

The one thing I'm still not sure about, though, is whether putting the test dependencies into the manifest with optional resolution is the smartest way to express them. If we used Maven, I could put 'em in the pom - but we don't.

What is the Best Way to capture test-only dependencies in an STS project?

You can use a TEST.MF file in your project to describe your test-only dependencies. There's some more information about this in Christian's blog.