如何在 maven 中表达对 java ee 功能的依赖以过渡到 Java 9? [英] How to express dependency in maven on java ee features for transition to Java 9?

问题描述

我们使用 maven 并拥有依赖于其他内部工件的工件.我正在迁移到 java-9，并打算首先将所有内容迁移到 Java 9，而不对代码进行模块化(即在未命名的模块中).

We use maven and have artifacts that in turn depend on other internal artifacts. I am in the process of migrating to java-9, and intend to migrate everything to Java 9 first without modularizing the code (i.e. in the unnamed module).

我遇到的问题是我们依赖 java.xml.bind，它现在不包含在默认模块中.是否有一种正确"的方式来表达这种对 java.xml.bind 与 Maven 的依赖关系?

The problem I run into is that we depend on java.xml.bind, which is now not included in the default modules. Is there a "correct" way to express this dependency on java.xml.bind with Maven?

推荐答案

模块系统发言在从类路径加载应用程序的情况下，未命名模块构建模块图的方式.此外，来自文档本身:-

The Module System speaks of the way the unnamed modules as in your case of loading the application from classpath constructs the module graph. Further, from the documentation itself:-

当编译器编译未命名模块中的代码时，或者java启动器被调用并加载应用程序的主类从类路径到应用程序类的未命名模块loader，则未命名模块的默认根模块集是计算如下:

When the compiler compiles code in the unnamed module, or the java launcher is invoked and the main class of the application is loaded from the class path into the unnamed module of the application class loader, then the default set of root modules for the unnamed module is computed as follows:

• java.se 模块是一个根，如果它存在的话.如果它不存在那么升级模块路径上或系统中的每个 java.* 模块exports 至少一个包的模块，没有限定，是一个根.

• The java.se module is a root, if it exists. If it does not exist then every java.* module on the upgrade module path or among the system modules that exports at least one package, without qualification, is a root.

升级模块路径上或系统中的每个non-java.*模块exports 至少一个包的模块，没有限定，是也是一个根.

Every non-java.* module on the upgrade module path or among the system modules that exports at least one package, without qualification, is also a root.

否则，默认的根模块集取决于阶段:

Otherwise, the default set of root modules depends upon the phase:

• 在编译时通常是正在编译的模块集(更多在下面);

• At compile time it is usually the set of modules being compiled (more on this below);

链接时为空；和

在运行时，它是应用程序的主模块，如通过--module(或简称 -m)启动器选项.

At run time it is the application's main module, as specified via the --module (or -m for short) launcher option.

偶尔需要将模块添加到默认根集为了确保特定的平台、库或服务提供商模块将出现在模块图中.在任何阶段都有选择

It is occasionally necessary to add modules to the default root set in order to ensure that specific platform, library, or service-provider modules will be present in the module graph. In any phase the option

--add-modules (,)* 其中 是模块名称，将命名模块添加到默认的根模块集.

--add-modules <module>(,<module>)* where <module> is a module name, adds the named modules to the default set of root modules.

在 jetty.project 中遇到了类似的问题，其中 thread 讨论了相同的问题，修复是使用:

Similar issue was faced in jetty.project where a thread from jdk mailing list discussed over the same and the fix was to use:

--add-modules java.se.ee

它为他们提供了对所有 Java SE 模块的访问权限，在您的情况下应该是:

which provided them access to all Java SE modules and in your case shall simply be:

--add-modules java.xml.bind

要在 maven 中使用它，您可以将其嵌入到 maven-compiler-plugin使用

To use this in maven, you can embed the same to the maven-compiler-plugin using

<compilerArgs>
    <arg>--add-modules</arg>
    <arg>java.xml.bind</arg>
</compilerArgs>

按照 ZhekaKozlov 的建议 此处.

as suggested by ZhekaKozlov here.

需要注意的重要一点是，将 API 标记为弃用也意味着您可能不想使用它.为了适应这种方式，您可能可以开始使用对 jaxb-api:2.3.0 现在可以作为模块加载，也可以从类路径中执行.您需要进行的更改是将以下内容添加到您的依赖项列表中:

An important point to note is that marking deprecation of an API also means you might probably want to get away from using it. To adapt to this way you can probably start consuming the dependency on jaxb-api:2.3.0 which can now be loaded as a module and can be executed from the classpath as well. The change you need to make is to add the following to your dependencies list:

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.0</version>
</dependency>

<小时>

更新:- 最终，随着 Java-10 和 JDK/11 已经发布，理想情况下应该点击 JEP 320:删除 Java EE 和 CORBA 模块，并进一步用它们的独立库替换这些依赖项.

---

Update:- Eventually, with Java-10 already out and JDK/11 up next, one should ideally follow the link to JEP 320: Remove the Java EE and CORBA Modules and further replace such dependencies with their standalone libraries instead.

这篇关于如何在 maven 中表达对 java ee 功能的依赖以过渡到 Java 9?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！