在公司中，我们做项目。项目可能已经编译过了，得到了target。 但是每一个人的编译环境不同，得到的target不同。 所以我们需要自己再重新先清空掉，然后再complie编译一次（在自己的编译环境之下）。
GroupId和ArtifactId被统称为“坐标”是为了保证项目唯一性而提出的，如果你要把你项目弄到maven本地仓库去，你想要找到你的项目就必须根据这两个id去查找。
GroupId一般分为多个段，这里我只说两段，第一段为域，第二段为公司名称。域又分为org、com、cn等等许多，其中org为非营利组织，com为商业组织。举个apache公司的tomcat项目例子：这个项目的GroupId是org.apache，它的域是org（因为tomcat是非营利项目），公司名称是apache，ArtifactId是tomcat。
每次创建项目时， IDEA 要使用插件进行创建，这些插件当你创建新的项目时，它每次都会去中央仓库下载，这样 使得创建比较慢。应该创建时，让它找本地仓库中的插件进行创建项目。 -DarchetypeCatalog=internal
我的 别人的
选src下面的java文件夹
maven有一个核心功能是一键构建：不再使用本地的tomcat，而是使用maven自身集成Tomcat插件。
scope的值有以下几种可能，进行分情况讲解： compile 默认就是compile，什么都不配置也就是意味着compile。compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。默认的scope,在部署的时候将会打包到lib目录下，项目在编译，测试，运行阶段都需要
test scope为test表示依赖项目仅仅参与测试相关的工作，在编译和运行环境下都不会被使用，更别说打包了。
runntime runntime这个scope，仅仅适用于运行环境，在编译和测试环境下都不会被使用
provided provided适合在编译和测试的环境，他和compile很接近，但是provide仅仅需要在编译和测试阶段，同样provide将不会被打包到lib目录下。
system 从参与度来说，也provided相同，不过被依赖项不会从maven仓库抓，而是从本地文件系统拿，一定需要配合systemPath属性使用。
scope的依赖传递 A–>B–>C。当前项目为A，A依赖于B，B依赖于C。知道B在A项目中的scope，那么怎么知道C在A中的scope呢？答案是： 当C是test或者provided时，C直接被丢弃，A不依赖C； 否则A依赖C，C的scope继承于B的scope。
为什么需要区分这些scope 可以用来限制dependency的范围可以在不同的环境下打包不同的jar包，比如junit测试类的jar包不需要在编译运行的时候，就可以设置scope为test。
查找了一下，很有可能是jdk不兼容，我用的是jdk11、12，视频使用的是jdk1.8 到时候需要下载jdk1.8，还有改环境变量。
Java SE 8就是Java8，或者jdk1.8。
Java各个版本发行日期：
1 JDK Alpha and Beta (1995)
2 JDK 1.0 (January 23, 1996)
3 JDK 1.1 (February 19, 1997)
4 J2SE 1.2 (December 8, 1998)
5 J2SE 1.3 (May 8, 2000)
6 J2SE 1.4 (February 6, 2002)
7 J2SE 5.0 (September 30, 2004)
8 Java SE 6 (December 11, 2006) 8.1 Java 6 updates
9 Java SE 7 (July 28, 2011) 9.1 Java 7 updates
10 Java SE 8 (March 18, 2014) 10.1 Java 8 updates
修改了javahome为1.8
