1

今天我清理了我的 .ivy 缓存并清理了我的项目输出目标。从那时起，我在使用 SBT 运行测试或在 Scala IDE 中进行编辑时遇到了非常奇怪的行为。

鉴于以下情况：

package com.abc.rest

import com.abc.utility.IdTLabel

我会收到以下错误：

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

请注意，com.abc它重复了两次，因此编译器在执行导入时似乎使用了当前包的上下文（也许它应该这样做，但我以前从未注意到它）。

此外，如果我尝试从包com.abc中的任何位置com.abc.rest（即使使用完整路径）访问包中的类，编译器也会抱怨找不到类型。

似乎只有当我尝试包含父包中的文件时才会出现错误。我觉得奇怪的是我的代码曾经可以工作。它只是在我清理了我的项目和我的常春藤缓存之后才开始发生的，所以也许更高版本的编译器比以前的版本更严格。

我很想知道我可能做错了什么，或者我可以如何解决这个问题。

更新：

通过首先导入父类，然后定义当前包，问题就消失了：

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

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

所以这行得通，但我仍然很想知道为什么反过来工作，然后停止工作，以及我到底该如何解决它。我仔细看了看，在父包中的任何地方都找不到以 com 为名的包、对象或特征。

与工作表相关的更新：

属于同一个包的 Scala 工作表共享相同的范围，这听起来很明显，但事实并非如此。工作表不是沙盒式的——它们可以看到项目，项目也可以看到它们。因此，您在工作表文件中创建的所有“测试”对象、特征和类也将在项目的其余部分中可见。

我有这么多工作表，我什至没有试图找出问题出在哪里。我只是将它们全部移到了自己的包中，就像魔术一样，问题就消失了。

因此，今天的经验教训是：如果您在工作表内创建内容，则可以从工作表外部看到它。

无论如何，这些新发现的知识将派上用场，这意味着可以在工作表中构建、监控和调整任何“有趣”的东西，而项目的其余部分可以实际使用它。其实很酷。

sbt clean想想一个和清理过的常春藤缓存如何设法突出以前隐藏的问题仍然很有趣，但是嘿，那是另一个故事......

4

2 回答 2

3

（应 JacobusR 的要求，我正在根据我之前的评论做出正确的回答）。

如果您在 package 中定义了一些类/特征/对象，就会发生这种情况com.abc.rest.com。一旦 packagecom.abc.rest.com存在，并且假设您在 package 中com.abc.rest，com将指定com.abc.rest.com而不是_root_.com. 最快（但非决定性）的检查方法是在“com/abc/rest/com”子文件夹中查找任何 .class 文件，甚至无需扫描源文件。

特别是，如果您的任何文件具有重复的包定义（如在 package 中com.abc.rest; package com.abc.rest; ...），您将获得此行为。如果您在出现错误的同一文件中的某处有此重复的包子句，您甚至不会看到 .class 文件有任何可疑之处，因为编译文件失败会阻止为任何类生成 .class 文件文件中的定义。

最后一点有用的信息是，当您发现 scala 工作表没有沙盒化时，您在工作表中定义的内容会影响您的项目代码（而不仅仅是让项目的代码影响工作表）。因此，工作表中的重复包子句很可能会导致您遇到错误。

于 2013-02-07T18:27:46.010 回答
1

如果包名称冲突，则可能会出现自定义错误消息。查看指定完整路径是否可以通过从__root__. 前任。import __root__.com.foo.bar._

于 2013-02-06T22:02:47.290 回答