我有一个JDK 9项目。在运行mvn install时,一切正常。在JDK9.0.4中使用IntelliJ 2017.2.6时,我会发现由于拆分包而产生的数十个编译错误。例如,在我的POM中,我设置了对org.apache.solr:solr-core:7.2.1的依赖。IntelliJ显示的错误之一是:
Error:java: module solr.core reads package org.apache.lucene.search from both lucene.misc and lucene.sandboxIntelliJ发布的编译错误的基本原理是:
solr-core对工件lucene-misc和lucene-sandbox有Maven依赖关系lucene-misc.jar和lucene-sandbox.jar都在包org.apache.lucene.search中定义类。lucene-misc.jar和lucene-sandbox.jar是JDK 9模块(事实上,它们不是模块,它们没有module-info.java文件)。由于两个JDK 9模块不能参与同一个包,IntelliJ发出编译错误。相比之下,Maven编译器插件不会出错,因为它认为lucene-misc.jar和lucene-sandbox.jar属于类路径,而不是模块路径。
我显然不想重新包装Lucene的东西。
因此,我的问题归结为以下几个方面:如何静音IntelliJ错误Error:java: module Mod1 reads package P from both Mod2 and Mod3
发布于 2018-02-22 16:02:54
短
如果您想要从模块代码运行应用程序,这是不可能的。您必须将依赖于碰撞jar的代码迁移到_non_e代码,并在类路径上添加冲突jar。(如评论中所建议)
Long
在场景后面,Intellij尝试运行JVM,因此Intellij只能在JVM能够运行的情况下运行您的应用程序。
当您从模块jar运行应用程序时,这意味着您从命名模块运行应用程序。模块必须要求它的所有依赖项,这些依赖项应该是名称模块。请注意,即使是从非模块module_s创建的自动_JARs也确实被命名了。由于可靠的配置,Java 9不允许拆分包,只有_unnamed module_s例外于此规则。
使其工作的唯一方法--将碰撞罐移动到未命名的模块,但命名模块不能依赖未命名模块
事实上,命名模块甚至不能声明对未命名模块的依赖。这种限制是有意的,因为允许命名模块依赖类路径的任意内容将使可靠的配置变得不可能。
因此,如果您不想重新打包冲突罐,您必须将需要碰撞jar的模块移动到非模块jar。
您的maven插件已经完成了,因为正如@Nicolai所说:
Maven将它们放置在类路径上(拆分包并不重要),而IntelliJ将它们放置在模块路径上(导致您观察到的问题)。
还请参阅关于从非模块代码运行应用程序的这个答案。
https://stackoverflow.com/questions/48871059
复制相似问题