idea工具 maven构件项目的时候，提示程序包javax.xml.ws.soap不存在

使用idea的工具构件maven项目出现：程序包javax.xml.ws.soap不存在

使用调试方法的 “溯源法”和“演绎法”去解决问题

溯源法：从出错位置人工沿着控制流程往回追踪，直至发现错误的根源。

演绎法：提供错误结果，列出所有可能错误的原因。

查看maven构件过程：

发现提示：compilation error 编译错误。

这这个类中的第18行有一个错误，关键字ERROR

找到这个类的第18行，发现是javax

java和javax都是Java的API(Application Programming Interface)包，java是核心包，javax的x是extension的意思，也就是扩展包。java类库是java发布之初就确定了的基础库，而javax类库则是在上面增加的一层东西，就是为了保持版本兼容要保存原来的，但有些东西有了更好的解决方案，所以，就加上些，典型的就是awt(Abstract Windowing ToolKit) 和swing。

演绎法分析可能原因：

       1：依赖包没有安装（根据javax排除）

       2：jdk没有安装（根据项目以往可以构建，本次不能构建，排除）

       3：jdk版本不对  

排查jdk版本问题：

     从日志中得出是编译出了问题，问idea是如何确定项目的编译环境？

     file->project structure,配置当前项目的设置

发现问题：发现我当前使用的jdk15。为什么我会使用的是jdk15而不是别的。

  XXXXXXXX未找到原因XXXXXXXXXXX以后再说

解决问题：然后切换我需要的版本jdk1.8

--------------------------------------------分割线---------------------------------------------------------------

从java11开始，Java EE模块已经被删除，不再有JAX-WS模块。

如果真的要使用jdk15编译，需要添加依赖

<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-ri</artifactId>
    <version>2.3.2</version>
    <type>pom</type>
</dependency>

去jdk官网找个根源：

JDK 11
JDK 11 is the open-source reference implementation of version 11 of the Java SE Platform as specified by by JSR 384 in the Java Community Process.

JDK 11 reached General Availability on 25 September 2018. Production-ready binaries under the GPL are available from Oracle; binaries from other vendors will follow shortly.

The features and schedule of this release were proposed and tracked via the JEP Process, as amended by the JEP 2.0 proposal. The release was produced using the JDK Release Process (JEP 3).

Features
181: Nest-Based Access Control
309: Dynamic Class-File Constants
315: Improve Aarch64 Intrinsics
318: Epsilon: A No-Op Garbage Collector
320: Remove the Java EE and CORBA Modules
321: HTTP Client (Standard)
323: Local-Variable Syntax for Lambda Parameters
324: Key Agreement with Curve25519 and Curve448
327: Unicode 10
328: Flight Recorder
329: ChaCha20 and Poly1305 Cryptographic Algorithms
330: Launch Single-File Source-Code Programs
331: Low-Overhead Heap Profiling
332: Transport Layer Security (TLS) 1.3
333: ZGC: A Scalable Low-Latency Garbage Collector
(Experimental)
335: Deprecate the Nashorn JavaScript Engine
336: Deprecate the Pack200 Tools and API
Schedule
2018/06/28		Rampdown Phase One (fork from main line)
2018/07/26		Rampdown Phase Two
2018/08/16		Initial Release Candidate
2018/08/30		Final Release Candidate
2018/09/25		General Availability
Last update: 2019/3/19 17:06 UTC

320: Remove the Java EE and CORBA Modules；移除Java EE和CORBA模块

删除原因：

Motivation

Java SE 6 included a full Web Services stack for the convenience of Java developers. The stack consisted of four technologies that were originally developedfor the Java EE Platform: JAX-WS (Java API for XML-Based Web Services), JAXB (Java Architecture for XML Binding), JAF (the JavaBeans Activation Framework), and Common Annotations. At the time of inclusion, the versions in Java SE were identical to the versions in Java EE, except for Java SE dropping a package in Common Annotations that concerned the Java EE security model. However, over time, the versions in Java EE evolved, which led to difficulties for the versions in Java SE:

• The technologies gained features that were not relevant to Java SE. For example, Common Annotations added a package in Java EE 6 that concerned data sources in a Java EE container. This made it necessary to periodically snapshot and subset the Java EE versions, which was time consuming for JDK engineers and confusing for developers.

• The technologies were maintained by upstream projects on java.net and later on GitHub. This made maintenance problematic due to having to sync the Java SE versions in OpenJDK repositories with the Java EE versions in upstream repositories.

• It was possible for developers to obtain standalone versions of the technologies from the upstream projects and deploy them via the Endorsed Standards Override Mechanism. This longstanding mechanism allowed standalone versions to safely override the Java SE versions. Unfortunately, it was not widely used in practice, and developers instead used ad-hoc mechanisms to deploy standalone versions, such as prepending them to the JDK's bootstrap class path, or simply placing them on the class path and hoping that the resulting split packages would not cause problems.

Since standalone versions of the Java EE technologies are readily available from third-party sites, such as Maven Central, there is no need for the Java SE Platform or the JDK to include them.

Another case of Java SE including technologies for developer convenience dates back to 1998. Under Ken Cavanaugh's distinguished leadership, Java SE embracedCORBA by shipping the OMG CORBA API, an ORB implementation, a CosNaming implementation, the idlj compiler, and support for IDL and IIOP in the rmiccompiler. However, over time, support for CORBA became problematic:

• Since CORBA is an "Endorsed Standard" that evolves outside the Java Community Process, comments similar to those for Web Services apply to the maintenance of CORBA in the JDK and to the ability to safely override the JDK's CORBA implementation. There is no realistic prospect of synchronizing the ORB in the JDK with the ORBs in Java EE application servers.

• There is no significant interest in developing modern applications with CORBA in Java. Furthermore, Java EE 8 lists CORBA, RMI-IIOP, and JavaIDL as "Proposed Optional", indicating that required support for these technologies may be dropped in future.

Since the costs of maintaining CORBA support outweigh the benefits, there is no case for the Java SE Platform or the JDK to include it.

Finally, Java SE has included a subset of JTA (Java Transaction API) since Java SE 1.3 and a subset of the J2EE Activity Service for Extended Transactions (J2EE Activity Service) since Java SE 5.0.

JTA consists of two packages that play different roles and deserve different treatment:

• The javax.transaction.xa package supports XA transactions in JDBC. This "XA package" is co-located with JDBC in the java.sql module in Java SE 9. Because the java.sql module is not upgradeable, it is not possible for a standalone version of JTA to override the Java SE version of the XA package, but this is generally acceptable to applications because the XA package has been stable for many years and the Java SE version is identical to the Java EE version. For ease of maintenance, the XA package in Java SE may be moved to a different non-upgradeable module in the future, but as an architectural matter it will remain in Java SE alongside JDBC for the long term, and is of no further interest to this JEP.

• The javax.transaction package defines a general transaction management API. The Java EE version of this package was always beyond the scope of Java SE and has evolved in ways that are not relevant to Java SE. For example, JTA added types in Java EE 7 that concern CDI. The subset of javax.transaction defined by Java SE supports interoperation with CORBA transaction services. This "CORBA interop package" exists in its own java.transaction module in Java SE 9. However, the Java SE version is generally not acceptable to applications that use CORBA transaction services, so they usually override it with the Java EE version.

The J2EE Activity Service defines a generic middleware API. It has not been updated since 2006 and is not part of the Java EE Platform. It is relevant to this JEP only because Java SE includes a subset of one of its packages, javax.activity, for interoperation with CORBA transaction services. This "activity package" exists in the java.corba module in Java SE 9.

Without CORBA support in the Java SE Platform or the JDK, there is no case for including the CORBA interop package from JTA or the activity package from the J2EE Activity Service.