1.Maven的简介Maven 是一款基于Java平台的项目管理和整合工具，它将项目的开发和管理过程抽象成一个项目对象模型在xml文件中进行声明，pom.xml就是这个模型文件。开发人员只需要在这个xml配置文件中做一些简单的配置，Maven 就可以自动完成项目的编译、测试、打包、发布以及部署等工作，本文中将对pom.xml文件中各个标签的简单总结。2.pom.xml文件中的各个标签的作用pom.xml为我们提供了很多标签来进行标识和构建我们所需要的各个依赖等等功能。groupId：项目组织的唯一标识符，即maven将项目打包到本地仓库的标识；artifactId：项目唯一标识，即maven将项目打包到本地仓库的标识；version：项目的版本号，可以自定义packaging：maven将项目打成包的格式，常用的一般有三种：jar、war和pom上面这些标签共同构建出了这个项目的坐标，maven会根据这些标签将这个项目打包到在本地仓库中项目坐标指定的位置中去。extensions：是否加载该插件的扩展,默认为false;inherited：表示该插件的标签中的配置是否可以被继承,默认为true；configuration：该插件所需要的特色配置,在父子项目项目之间可以覆盖或被合并；dependencies：这个应该是我们最经常使用的一部分，里面写的是本项目使用的第三方类库依赖，构建一个项目首先就是先把所需要的依赖加入到这里面去；dependency：位于dependencies标签内部的子标签，标识具体的依赖，其实依赖的本质就可以看做本项目所依赖的工程坐标或者说是依赖坐标，而maven则会先根据项目坐标到本地仓库中去寻找要使用的项目，找不到就会联网到setting指定的网站中去查找然后下载到本地仓库。dependency中也有自己的唯一标识和上面描述的groupId、artifactId、version三剑客是一样的，并且它还拥有自己的依赖的作用范围scope，这个范围是由几个值构成的：compile在不指定scope标签的时候，默认值就是compile，它的作用范围是包括项目的编译，运行，打包阶段，意味着被compile修饰的依赖都参与这些阶段；provided的作用范围只是编译阶段，在运行和打包均不参与。以上就是Maven标签的简单总结。

官方的样例代码里依赖的版本是这样的格式2.2.3-hw-ei-302002看不出来jar包版本与平台版本的关系正常来说应该是跟cdh一样要下对应平台版本的jar包吧？那得知平台版本号之后应该怎么确认jar包版本号呢比如说我现在平台的版本号是6.5.1，平台内hbase的版本号是1.3.1，那二次开发时对应依赖jar包的版本应该是什么

使用idea的工具构件maven项目出现：程序包javax.xml.ws.soap不存在使用调试方法的 “溯源法”和“演绎法”去解决问题溯源法：从出错位置人工沿着控制流程往回追踪，直至发现错误的根源。演绎法：提供错误结果，列出所有可能错误的原因。查看maven构件过程：发现提示：compilation error 编译错误。这这个类中的第18行有一个错误，关键字ERROR找到这个类的第18行，发现是javaxjava和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编译，需要添加依赖 com.sun.xml.ws jaxws-ri 2.3.2 pom去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 UTC320: Remove the Java EE and CORBA Modules；移除Java EE和CORBA模块删除原因：MotivationJava 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.

rt，公司没有git托管，需要自己写pom，但没接触过FI平台，不知道是不是跟CDH一样有对应CDH版本的依赖包，所以求一个

Maven源希望添加https://maven.scijava.org/content/repositories/public/https://maven.scijava.org/content/groups/public/

Java SmartAssist开发套件常用设置      语言服务启动成功后，设置弹窗中会出现Java SmartAssist开发套件的设置，即语言服务相关的所有设置，包含Java功能相关的设置、Maven及Gradle相关的设置和Validation设置。Maven相关设置1.什么是Bundled(Maven 3)？       Maven home默认版本为Bundled(Maven 3)，即CodeArts预安装的Maven，版本为3.6.3，同时会兼容maven2。2.如何修改Maven home？       Maven home配置中，您可以选择自带的Bundled Maven版本或已解析的系统变量（如MAVEN_HOME），也可以指定安装在计算机上的其他Maven版本。同时，CodeArts还支持手动输入目录或点击browse按钮并在打开的对话框中选择所需的目录。3.如何指定User settings file？       用户特定配置的文件，默认读取%HomePath%/.m2目录下的settings.xml文件。如果您需要指定另一个文件，请手动输入文件目录或点击browse按钮并在打开的对话框中选择所需的文件。4.如何指定Local repository？       Local repository默认的本地仓库路径为%HomePath%/.m2/repository，该目录存储下载配置文件。如果您需要指定另一个目录，请手动输入目录或点击browse按钮并在打开的对话框中选择所需的路径。5.如何设置Maven SDK？        默认为Project JDK，您可以点击下拉框选择其它版本的JDK（CodeArts会自动识别本地已安装的JDK）。6.Work offline的作用是什么？        如果选中此复选框，Maven 将在离线模式下工作，并且仅使用本地可用的资源。7.Print exception stack trace的作用是什么？        如果选中此复选框，则会生成异常堆栈跟踪。8.Use plugin registry的作用是什么？        如果选中此复选框，以启用对 Maven 的插件注册表的引用。9.Excute goals recursively的作用是什么？        如果选中此复选框，则将构建递归到嵌套项目中。Gradle相关设置1.什么是Gradle User Home？        Gradle User Home 用于存储全局配置属性和初始化脚本以及缓存、日志文件等。默认设置路径为%HomePath%/.gradle。2.可以修改Gradle User Home吗？        可以通过以下方式之一覆盖默认路径：您可以设置GRADLE_USER_HOME环境变量（例如，%APPDATA%/.gradle）。变量的值是自动获取的，新路径自动显示在Gradle User Home设置里。您可以手动指定位置：手动输入目录或点击browse按钮并在打开的对话框中选择所需的目录。3.如何设置Gradle SDK？        默认为Project JDK，您可以点击下拉框选择其它版本的JDK（CodeArts会自动识别本地已安装的JDK）。其他语言服务相关设置1.Project SDK默认是哪个版本？        如果JDK已安装在您的计算机上，项目初始化时，默认选择最高的JDK版本。2.Language level是什么？        Language level定义了编辑器提供的编码辅助功能。Language level可以与Project SDK 不同。例如，您可以使用 JDK 11并将Language level设置为 8。这使得字节码与 Java 8 兼容，同时检查确保您不使用 Java 11 中的constructs。CodeArts运行和调试常见问题1.如何在运行主类main方法前配置更多的运行参数？        CodeArts支持配置更多的运行参数来调试程序，点击右上角调试工具栏default选择Edit，在属性对话框中添加和修改，目前已支持配置主类、命令行参数、环境变量、JVM配置参数及缩短运行命令行配置，将来我们会有更多的支持。2.如何启动多个调试？        CodeArts暂不支持并行运行和调试，新启动一个调试的时候会提示是否结束已启动的调试进程并启动当前的调试。Maven下载依赖代理问题1、CodeArts设置的代理和Maven的settings.xml中的代理相比，哪个优先级更高？        CodeArts设置的代理优先级更高。Maven的settings.xml中的代理配置如下图：2、如果下载依赖，报407状态码错误，该如何处理？        当代理设置在配置文件settings.xml中时，需要在settings.xml中配置username和password。        当代理设置在CodeArts的设置项中时，在设置中搜索proxy，找到proxy Username和proxy Password设置项，并进行相应的配置。 Gradle下载依赖代理问题1、下载Gradle的zip包时怎么配置代理？        在CodeArts设置中配置代理即可。Gradle工程自动下载gradle/wrapper/gradle-wrapper.properties文件的distributionUrl的zip包，需要提前配置好CodeArts设置代理2、CodeArts设置的代理和Gradle的gradle.properties中的代理相比，哪个优先级更高？       CodeArts设置的代理优先级更高。Gradle的gradle.properties中的填写代理信息，如下图：CodeArts登录激活CodeArts登录激活会走CodeArts代理配置吗？当CodeArts设置配置代理时，在登录激活时会生效。华为云API开发常见问题1、如何解决证书问题？       在使用华为云API开发时，遇到如下报错时，即为jdk证书问题引起。解决办法：1>代码中忽略ssl校验        参考代码：        HttpConfig config = HttpConfig.getDefaultHttpConfig();        config.withIgnoreSSLVerification(true);2>jdk导入代理服务器证书或者代理服务器的所有父级证书       方法步骤（以华为证书为例）：       (1)、请用windows自带的cmd窗口，且使用管理员方式       (2)、安装命令：cd /d %JAVA_HOME%\jre\lib\security curl https://cmc-szver-artifactory.cmc.tools.huawei.com/artifactory/CMC-Release/certificates/HuaweiITRootCA.cer -o HuaweiITRootCA.cer curl https://cmc-szver-artifactory.cmc.tools.huawei.com/artifactory/CMC-Release/certificates/HWITEnterpriseCA1.cer -o HWITEnterpriseCA1.cer keytool -keystore cacerts -importcert -alias HuaweiITRootCA -file HuaweiITRootCA.cer -storepass changeit -noprompt keytool -keystore cacerts -importcert -alias HWITEnterpriseCA1 -file HWITEnterpriseCA1.cer -storepass changeit -noprompt(3)、检验：         声明：findstr命令执行后会有返回值cd /d %JAVA_HOME%\jre\lib\security keytool -list -V  -keystore cacerts -storepass changeit | findstr /n  huaweiitrootca keytool -list -V  -keystore cacerts -storepass changeit | findstr /n  hwitenterpriseca1(4)、清楚冗余：del  HuaweiITRootCA.cer del  HWITEnterpriseCA1.cer2、如何使用临时AK/SK调用华为云API        在使用华为云API开发时，华为云API插件提供的补全模板往往是使用永久AK/SK进行调用，代码如下：        如果使用临时AK/SK，相比于永久AK/SK多一个x-security-token参数，我们只需要在创建credentials的时候使用withSecurityToken()方法即可，参考如下代码：

已经在porm里面配置了maven仓库配置是默认配置但是报错这个去官方仓库里找到的是这个所以maven解析的时候3.5.6-hw-ei-310003-12.0版本号里面多出来了hw-ei-310003。手动修改版本号也不行。求助

        愉快又短暂的劳动节假期转瞬即逝，我收了收这颗放浪不羁的心，回到了我熟悉的工作岗位当中。往事如烟，回忆万千，有人醉里挑灯看剑，有人在电脑前编译构建；遥望窗外两行雁，低头error报错一脸。。。         我打开了我的devcloud专业版，执行了我的maven构建任务，没想到居然报错了，仔细看了下日志，原来是没有找到构建时需要的依赖包。        讲到这，我们不得不引入一个小概念~那就是maven工程中的pom文件--pom.xml，这个文件就像一个配方，一个配料表，告诉我们要想把java maven这道菜做好，需要去后厨仓库冰箱里拿哪些食材。还有一个东西，叫settings.xml，这是个配置文件，它会告诉我们，后厨的仓库冰箱在哪，我们需要去哪个冰箱里找食材。        那么问题来了~ 这次构建失败了，没有找到具体食材，原因是啥呢，我们该如何检查呢？        如果这个maven工程是一道宫保鸡丁~，那么我们的pom文件里写的就是配料表，里面写明了要求有鸡肉、黄瓜、胡萝卜、花生。settings文件里告诉了我们这些材料要去哪个仓库的哪个冰箱里找，要去后厨一进门左边那台海尔的四开门冰箱~ 而不是右边那台西门子的双开门冰箱~等等。 本着肥水不流外人田的原则，我们的原材料~也就是私有依赖包，肯定是上传放到我们自己的华为云私有依赖库中~ 那我们现在开始行动吧，去后厨冰箱找鸡肉！！       （1）点开我们的编译构建任务，点击编辑任务，确认一下我们的构建任务所对应的源码仓库和分支是什么，以及关联一下我们的maven仓库。       （2）确认了仓库后，我们找到这个仓库，观察一下我们的pom文件，看看我们的配料表。找到”dependency”这个标签，看看里面的源材料名称，也就是私有包的坐标名称。       （3）ok~ 确认了坐标信息后，我们去“仓库冰箱”里看看这个“食材”究竟在不在里面~ 点击我们的私有依赖库服务，找到我们的maven仓库，啊嘞嘞？我鸡肉呢？啊不，我私有包呢？原来是忘了把这个私有包传到我们的私有依赖库里，冰箱里没食材，这让厨子咋做饭啊？              （4）悄悄咪咪的在厨师长没发现之前~ 赶紧把冰箱填满！我们把本次构建所需要的私有依赖包完美上传一下~~       （5）起锅烧油，重新执行构建，成功的找到了这个食材，宫保鸡丁做好了~搞定！         这就是maven构建和maven私有依赖库的基本用法~ 一般人我不告诉他！

[问题描述】编译netty 4.0.8.Final时报tmaven版本not in the allowed range错误，详细报错如下：Detected Maven Version: 3.6.3 is not in the allowed range [3.0.5,3.1). 【解决方法】1、降低使用的maven版本为3.0.5到3.0.9，然后进行编译；2、修改pom.xml中maven版本的范围，从[3.0.5,3.1)修改为[3.0.5,3.7)，然后再次编译【注】：其他版本如遇到类似报错可参考相同解决方法；

# 编译构建模板的版本号问题 我的代码使用的 JDK 是 17 的版本，maven 版本是 3.8.1 创建流水线的时候，编译构建的 Maven 模板中没有我需要的版本号。 请问这种情况，在不修改我项目代码中的 JDK 和 Maven 版本的条件下，还能使用流水线的编译构建吗？

起初没有在pom文件指定maven仓，使用默认的构建仓说找不到这个依赖，后来修改为指定的仓后又报识别错误，请问下接下来应该怎么解决

<dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-api-scala_2.11</artifactId> <version>1.10.0-hw-ei-302002</version></dependency>这个报错，找不到这个这个。我配置的settings是    <mirror>      <id>huaweicloud</id>      <mirrorOf>*,!HuaweiCloudSDK</mirrorOf>      <url>https://repo.huaweicloud.com/repository/maven/</url>    </mirror>是哪里错了吗？

pom.xml中 没有repository标签  能加吗    怎么加   而且https://mirrors.huaweicloud.com/kunpeng/maven这里面的jar包不能搜索？怎么能快速找到自己想要的jar包呢

1. 移植环境类别版本OS银河麒麟V10 B06 for ARMJDK1.8.0_191Maven3.5.4netty4.1.32neo4j3.5.4 2. 软件准备2.1OpenJDK安装2.1.1下载并安装到指定目录#wget https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u191-b12/OpenJDK8U-jdk_aarch64_linux_hotspot_8u191b12.tar.gz#tar -zxf OpenJDK8U-jdk_aarch64_linux_hotspot_8u191b12.tar.gz#mv jdk8u191-b12 /opt/tools/installed/2.1.2配置Java环境变量：         #vim /etc/profile         添加以下内容：（以实际安装路径为准）         JAVA_HOME=/opt/tools/installed/jdk8u191-b12PATH=$JAVA_HOME/bin:$PATHexport JAVA_HOME PATH使修改的环境变量生效：#source /etc/profile2.1.3查看JDK版本#java -version2.2Maven安装2.2.1下载并安装到指定目录#Wget https://archive.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz#tar -zxf apache-maven-3.5.4-bin.tar.gz#mv apache-maven-3.5.4 /opt/tools/installed/2.2.2添加环境变量         #vim /etc/profile         添加以下内容（以实际路径为准）：MAVEN_HOME=/opt/tools/installed/apache-maven-3.5.4PATH=$MAVEN_HOME/bin:$JAVA_HOME/bin:$PATHexport MAVEN_HOME JAVA_HOME PATH使环境变量生效：#source /etc/profile2.2.3修改maven配置文件中的，本地仓、远程仓等：配置文件路径：/opt/tools/installed/apache-maven-3.5.4/conf/settings.xml本地仓库配置：（可选，可保持默认）<!--默认在“~/.m2/”目录下，可以按下行格式修改成你自己想保存的目录--><localRepository>/path/to/local/repo</localRepository>远程仓库配置：（可选，默认用maven2官方远程仓但访问慢，建议用国内maven仓）<!--修改成自己搭建的maven仓库，如果没有，可以使用下面的华为开源maven仓 --><mirror><id> huaweimaven</id><name> huaweicloud maven</name><url> https://mirrors.huaweicloud.com/repository/maven/</url><mirrorOf>central</mirrorOf></mirror>配置代理：（可选，外网环境下不用配置maven的代理）  <proxies>   <proxy>      <id>optional</id>      <active>true</active>      <protocol>http</protocol>      <username>用户名</username>      <password>密码</password>      <host>代理服务器网址</host>      <port>代理服务器端口</port>      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>    </proxy>  </proxies> 3. 依赖包安装netty-all-4.1.32.Final.jar移植此组件在鲲鹏上已经编译，可以直接下载上传到本地Maven仓。将此jar包拷贝到以下路径#cp  netty-all-4.1.32.Final.jar  /root/.m2/repository/io/netty/netty-all/4.1.32.Final/4. Neo4j-3.5.4编译安装4.1设置相关约束条件#ulimit -HSn 400000#export MAVEN_OPTS="-Xmx512m"4.2下载Neo4j源码下载路径：https://github.com/neo4j/neo4j/tree/3.5.44.3编译将下载的源码上传到服务器并解压。#unzip neo4j-3.5.4.zip#cd neo4j-3.5.4/#mvn clean install –DskipTests编译完成的压缩包在packaging/standalone/target目录下5. 运行验证5.1将编译完成的压缩包拷贝包”/opt/tools”并解压。#cp neo4j-community-3.5.4-SNAPSHOT-unix.tar.gz /opt/tools/#cd /opt/tools#tar –zxvf neo4j-community-3.5.4-SNAPSHOT-unix.tar.gz5.2修改neo4j.conf配置文件。#vim conf/neo4j.conf# 修改54行，去掉改行的#，可以远程通过ip访问neo4j数据库dbms.connectors.default_listen_address=0.0.0.0# 默认 bolt端口是7687，http端口是7474，https关口是7473，不修改下面3项也可以# 修改71行，去掉#，设置http端口为7687，端口可以自定义，只要不和其他端口冲突就行#dbms.connector.bolt.listen_address=:7687# 修改75行，去掉#，设置http端口为7474，端口可以自定义，只要不和其他端口冲突就行dbms.connector.http.listen_address=:7474# 修改79行，去掉#，设置http端口为7473，端口可以自定义，只要不和其他端口冲突就行dbms.connector.https.listen_address=:74735.2关闭防火墙#systemctl stop firewalld#systemctl disable firewalld5.3启动neo4j进入bin目录执行./neo4j start#cd bin/#./neo4j start5.4使用PC可以访问neo4j的web页面http://ipaddress:7474第一次登录的用户名密码都为neo4j5.5停止neo4j#./neo4j stop5.6查看状态#./neo4j status 

【功能模块】       hive样例工程【操作步骤&问题现象】1、配置settings文件后，更新maven依赖，一直更新不成功，报下面的错误2、【截图信息】Could not transfer artifact org.apache.hadoop:hadoop-auth:pom:3.1.1-hw-ei-310003 from/to nexus-aliyun (https://maven.aliyun.com/repository/public): transfer failed for https://maven.aliyun.com/repository/public/org/apache/hadoop/hadoop-auth/3.1.1-hw-ei-310003/hadoop-auth-3.1.1-hw-ei-310003.pom【日志信息】（可选，上传日志内容或者附件）