Question

Today I cleared my .ivy cache and cleaned my project output targets. Since then I have been getting really strange behaviour when running tests with SBT or editing in the Scala IDE.

Given the following:

package com.abc.rest

import com.abc.utility.IdTLabel

I will get the following error:

object utility is not a member of package com.abc.rest.com.abc

Notice that com.abc is repeated twice, so it appears that the compiler uses the context of the current package when doing the import (maybe it’s supposed to do this, but I never noticed it before).

Also, if I try to access classes in package com.abc from anywhere inside com.abc.rest (even using the full path) the compiler will complain that the type can not be found.

It appears that the errors only occur when I try to include files from parent packages. What I do find strange is that my code used to work. It only started happening after I cleaned up my project and my ivy cache, so maybe a later version of the compiler is more strict than the previous one.

I would love some ideas on what I can be doing wrong, or how I can go about troubleshooting this.

Update:

By first importing the parent classes and then defining the current package, the problem goes away:

import com.abc.utility.IdTLabel
import com.abs._

package com.abc.rest {
 // Define classes belonging to com.abc.rest here
}

So this works, but I would still love to know why on earth the other way around worked, and then stopped working, and how on earth I can fix it. I had a good look, and could find no packages, objects or traits by the name of com anywhere inside the parent package.

Update relating to Worksheets:

Scala worksheets belonging to the same package share the same scope, which sounds obvious, but wasn’t. Worksheets are not sand-boxed – they can see the project, and the project can see them. So all the ‘test’ object, traits, and classes you create inside the worksheet files, also becomes visible in the rest of the project.

I have so many worksheets that I did not even try to see where the problem came in. I simply moved them all to their own package, and like magic, the problem went away.

So, lesson learned for the day: If you create stuff inside worksheets, it’s visible from outside the worksheet.

Anyway, this new found knowledge will come in handy, meaning anything ‘interesting’ can be build, monitored and tweaked inside the worksheet, while the rest of the project can actually use it. Quite cool actually.

It’s still interesting to think how a sbt clean and cleaned up ivy cache managed to highlight the problem that was hidden before, but hey, that’s another story….

Answer 1

(At the request of JacobusR, I’m making a proper answer out of my earlier comments).

This can happen if you have defined some class/trait/object inside package com.abc.rest.com. As soon as package com.abc.rest.com exists, and given that you are in package com.abc.rest, com would designate com.abc.rest.com as opposed to _root_.com. Fastest (but non-conclusive) way to check, without even scanning the source files, is to look for any .class files in the “com/abc/rest/com” sub-folder.

In particular you would get this behaviour if any of your files has duplicate package definitions (as in package com.abc.rest; package com.abc.rest; ...). If you have this duplicate package clause somewhere in the same file where you get the error, you wouldn’t even see anything fishy with the .class files, as the failure at compiling the file would prevent the generation of .class files for any class definition inside the file.

The final bit of useful information is that as you found out the scala Worksheets are not sandboxed, and what you define in the worksheets affects your project’s code (rather than only having the project’s code affecting the worksheet). So a duplicate package clause in a worksheet could very well cause the error you got.