Java 9 无法解析自动模块依赖/找不到模块
Java 9 automatic module dependencies cannot be resolved / module not found
我正在尝试将一些遗留应用程序迁移到新的 Java 9 模块系统，以加强其封装。
我从外向内开始，假设外围的 classes 具有最少的外部依赖性。
如您所料，我已经声明了一个非常开放的模块：
module com.example.user {
exports com.example.user;
}
这会立即破坏整个项目（在所有 classes 中），当突然每次导入外部依赖项时不再解决（导致超过 1k Java 问题）：
The import com.otherexample cannot be resolved
The import org.springframework cannot be resolved
etc.
同一项目中的本地包 com.example.price 仍然有效 - java.util 等
所有外部依赖项都是（曾经）使用 Maven 管理的。在（Eclipse 项目）构建路径中，我仍然可以将它们视为 "Classpath" 依赖项 - 但只有 "Modulepath".
中的 JRE 系统库
这两个概念可以共存吗？目前看来，在项目的任何地方都有一个 module-info.java，所有 class 路径依赖项都停止工作了吗？
我读过有关使用 automatic modules 的内容，这似乎暗示您可以通过将旧版/非模块化 jar 包含在您的模块路径中来使用它们，然后通过它们的文件名引用它们。他们使用示例：
module com.foo.myapp {
requires guava; // guava not yet modularised, so use the filename
}
我找不到太多其他信息，但这似乎符合 Eclipse 在自动生成模块时使用的约定 - info.java 例如：
spring-core-4.3.8.RELEASE.jar
变为：
requires spring.core;
但是，这仍然会导致 Eclipse 报 Java 错误：
spring.core cannot be resolved to a module
Maven 报告：
[ERROR] module-info.java:[39,16] error: module not found: spring.core
...并且项目中每个具有外部依赖性的 class 仍然被破坏。
感谢 Robert Scholte 指出更新的 maven-compiler-plugin 3.7.0（我一直在使用 3.6.1），这确实清理了编译目标命令行输出（使用 Java 9 细节），帮助我找到问题的路径。这缩小了每个 requires 报告的错误，给我的错误是：
[WARNING] ********************************************************************************************************************
[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *
[WARNING] ********************************************************************************************************************
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 56 source files to ./target/classes
~~~ snip ~~~
[ERROR] module-info.java error: module not found: foo.bar
匹配的 Eclipse：
foo.bar cannot be resolved to a module
只有六个自动模块/库 (jar) 出现错误，而不是全部 (24) 个。太好了。
在我的 POM 中，我将源目录的输出拆分到它们自己的输出目录 (target/classes)。但是，由于 module-info.java 引用了该文件夹中的代码 (类) 未使用/引用的依赖项（例如 requires spring.core;） - 它无法解析它们。
为什么？基本 Maven 依赖管理 - 我将这些库限定在默认目标之外（以匹配输出目录拆分）。
一个相当基本的结果 - 但我想我不会是唯一遇到这种情况的人，因为 Java 开始侵占与 Maven 的传统使用重叠的依赖管理的某些方面。
我正在尝试将一些遗留应用程序迁移到新的 Java 9 模块系统，以加强其封装。
我从外向内开始，假设外围的 classes 具有最少的外部依赖性。
如您所料，我已经声明了一个非常开放的模块：
module com.example.user {
exports com.example.user;
}
这会立即破坏整个项目（在所有 classes 中），当突然每次导入外部依赖项时不再解决（导致超过 1k Java 问题）：
The import com.otherexample cannot be resolved
The import org.springframework cannot be resolved
etc.
同一项目中的本地包 com.example.price 仍然有效 - java.util 等
所有外部依赖项都是（曾经）使用 Maven 管理的。在（Eclipse 项目）构建路径中，我仍然可以将它们视为 "Classpath" 依赖项 - 但只有 "Modulepath".
中的 JRE 系统库这两个概念可以共存吗？目前看来，在项目的任何地方都有一个 module-info.java，所有 class 路径依赖项都停止工作了吗？
我读过有关使用 automatic modules 的内容，这似乎暗示您可以通过将旧版/非模块化 jar 包含在您的模块路径中来使用它们，然后通过它们的文件名引用它们。他们使用示例：
module com.foo.myapp {
requires guava; // guava not yet modularised, so use the filename
}
我找不到太多其他信息，但这似乎符合 Eclipse 在自动生成模块时使用的约定 - info.java 例如：
spring-core-4.3.8.RELEASE.jar
变为：
requires spring.core;
但是，这仍然会导致 Eclipse 报 Java 错误：
spring.core cannot be resolved to a module
Maven 报告：
[ERROR] module-info.java:[39,16] error: module not found: spring.core
...并且项目中每个具有外部依赖性的 class 仍然被破坏。
感谢 Robert Scholte 指出更新的 maven-compiler-plugin 3.7.0（我一直在使用 3.6.1），这确实清理了编译目标命令行输出（使用 Java 9 细节），帮助我找到问题的路径。这缩小了每个 requires 报告的错误，给我的错误是：
[WARNING] ********************************************************************************************************************
[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *
[WARNING] ********************************************************************************************************************
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 56 source files to ./target/classes
~~~ snip ~~~
[ERROR] module-info.java error: module not found: foo.bar
匹配的 Eclipse：
foo.bar cannot be resolved to a module
只有六个自动模块/库 (jar) 出现错误，而不是全部 (24) 个。太好了。
在我的 POM 中，我将源目录的输出拆分到它们自己的输出目录 (target/classes)。但是，由于 module-info.java 引用了该文件夹中的代码 (类) 未使用/引用的依赖项（例如 requires spring.core;） - 它无法解析它们。
为什么？基本 Maven 依赖管理 - 我将这些库限定在默认目标之外（以匹配输出目录拆分）。
一个相当基本的结果 - 但我想我不会是唯一遇到这种情况的人，因为 Java 开始侵占与 Maven 的传统使用重叠的依赖管理的某些方面。