先说下本篇随笔的目录。

　　　　1、介绍windows中环境变量Path与ClassPath的区别。

　　　　2、可能导致命令行运行javac编译成功，但 java命令 + 所要执行的类的类名 无效的原因。

　　　　3、介绍Maven项目的结构。

　　　　4、Eclipse中添加Jar包的两种方式Add Jars 与 Add External Jars 的区别。

　　　　5、Eclipse发布项目到Tomcat上可能导致Jar包丢失的原因。

　　　　一、windows中环境变量Path与ClassPath的区别。

　　　　Path变量：当你打开Windows的CMD（命令行窗口）时，若想执行一个exe文件，就需要先进入此exe文件所在的目录，之后再输入此exe文件的名称来执行此exe文件。

　　　   那么问题来了，为什么我们只要打开了CMD窗口，不论我们当前处在什么路径，输入java命令都会有对应的提示呢？（也就是并不需要进入到java.exe所在目录才能执行java.exe文件）（如下图）

　　　     我的Java.exe文件在C:\Program Files\Java\jdk1.8.0_20\bin目录下，也就是说虽然我现在的位置是D盘根目录，但是我输入了java命令，仍然执行了java.exe文件。这里面就是Path环境变量在起作用。

　　　　　　上面这张图片就是我电脑上Path环境变量的设置情况。其中有一个就是%JAVA_HOME%\bin,也就是我电脑上JDK安装目录下的bin目录，在这个bin目录下就有我们刚刚执行的java.exe文件。

　　　　　　当我们在CMD中输入一条命令时，比如上面的java命令，操作系统会在当前目录下查找是否有名字为java.exe的可执行文件，如果当前目录下没有找到，就会在环境变量Path中设置的路径下面去找，比如上面的%JAVA_HOME%\bin路径下，如果找到了，就会执行相应的exe文件，如果找不到，就会提示当前输入的命令不存在。

　　　　　　也就是说，Path环境变量可以简化我们输入的命令的作用，如果我们java这条命令用的频繁的话，就可以通过设置Path变量来达到只输入java就可以执行，而不必进入到其所在的目录才能执行，可以减少我们的重复工作。

　ClassPath变量：ClassPath顾名思义，可以理解为Java的类查找路径。这也是ClassPath与Path主要的区别，Path环境变量是操作系统使用的，而ClassPath是Java编译器用来查找代码中用到的类的路径的。

　　　举例：

1 package com.cnblog;
2 import undact.utils.GetTime; 3 public class Test {4     public static void main(String[] args) {5         System.out.println(GetTime.GetNowTime());6     }7 }

　　    　在这个Test类中，我导入了一个自定义的包undact.utils中的GetTime类,那么当我在CMD中用javac编译此文件时为什么可以正确的找到这个类，通过编译呢？

　　　　 因为我在环境变量的设置中在ClassPath环境变量中加上了undact.utils.GetTime类所在的路径，这样在编译时编译器就会通过查找ClassPath从而找到我引入的这个类，正确的对Test类进行编译。这也就是ClassPath环境变量的功能。

　　二、可能导致命令行运行javac编译成功，但 java命令 + 所要执行的类的类名 无效的原因。

　　　  　还是以上面的Test.java文件为例，假设此文件的存放目录为C:\Users\lenovo\Desktop\com\cnblog\Test.java,那么当我们在CMD中进入到C:\Users\lenovo\Desktop目录下，就可以通过javac Test.java命令对Test.java文件进行编译，你也确实可以看见在当前目录下生成了Test.class文件，但当你输入java com.cnblog.Test时却发现提示找不到主类。这是由于Test.java有自己所在的package，并不是属于default package，所以你必须进入到其所在包的上一级目录输入命令才能执行，也就是说在本例中，你需要进入到C:\Users\lenovo\Desktop目录下再输入java com.cnblog.Test命令才能正确的执行。

　　三、介绍Maven项目的结构。

              如左图所示，为典型的maven web项目结构，正规些的里面还要用到src/test/java及src/test/resource文件夹。右图为普通的web项目结构，都是使用Eclipse for JavaEE Developers 版本的Eclipse构建的。关于maven构建项目的好处及如何使用maven我这里不谈，只讲下如何理解这样的结构。有很多刚刚用maven构建web项目的人来说，有最疑惑的问题可能就是这种项目结构与我构建的普通web项目结构有何区别？如何把我以前做项目的经验适用到这样的项目结构中来？

　　　　　其实不论是maven web项目，还是普通的web项目，部署到服务器之后，其结构都是相似的，那么为什么从eclipse上看两种结构差异这么大，部署到服务器上结构却又差不多呢？这其实是源于eclipse的配置选项，看懂这个配置就能明白这个问题了。

　　　　　　上图即为将一个Maven web项目部署到服务器上时的可选配置。source一栏代表你在Eclipse中看到的项目的结构，Deploy Path一栏代表部署后的对应路径。也就是说src/main/java这个文件夹在部署到服务器上时将会被部署到对应的WEB-INF/class文件夹中，而Maven Dependencies中涉及到的jar包将会被部署到WEB-INF/lib文件夹中，其余以此类推。

　　　　　　接下来我们再来看下一个普通web项目在部署到服务器上时的可选配置。

　　　　　　　可以看到项目中的/WebContent文件夹部署到服务器上时被放置在了服务器上此项目的根目录中，/src文件夹则被放置在了服务器上的WEB-INF/classes文件夹下，与上述maven项目中src/main/java文件夹默认放置的路径是相同的。

　　　　　　　无论是普通web项目，还是maven web项目，在服务器上项目结构都大致如下图：

　　　　　　　这样也有利于服务器统一对web项目的管理。

　　　　　　　由于上述原因，所以不论是maven web项目，还是普通的web项目，部署到服务器之后，其结构都是相似的。这样我们就可以很容 易的把以前做普通web项目的经验适用到maven web这样的项目结构中。

　　四、Eclipse中添加Jar包的两种方式Add Jars 与 Add External Jars 的区别。

　　　　　　 当我们在项目中需要引入外部的jar包时，常用的可以有以下两种选择方式，

　　　　　         图1          图2

 　　　　　　图1为点击Add Jars后的Eclipse中的选项，图2为Add External Jars 后的Eclipse中的选项。两图比较可以看出，Add Jars是让你在当前的工程中选择jar包添加，Add External Jars是在任意位置选择jar包添加。两种方式均可，对我个人而言，常用的方式是在当前工程中新建一个lib文件夹，之后把要添加的jar包复制到此文件夹中，然后再利用Add Jars的方式把lib中的jar包添加到工程的Reference Library当中去。这样做的好处是保证用到的jar包始终在工程中，不会被误删，便于项目的移植。Add External Jars 方式引入的Jar包可能会被不小心误删掉，比如说引入的jar包放在了桌面，清理桌面的时候误删jar包就会导致工程运行出错。

　　五、Eclipse发布项目到Tomcat上可能导致Jar包丢失的原因。

　　　　　　如四所说，通过Add External Jars 方式引入的jar包在部署到服务器上时并没有被拷贝，就会导致jar包丢失，运行时找不到jar包。

　　　　而通过在项目中建立lib文件夹的方式引入外部jar包，在部署到服务器上时会根据你的配置选项把jar包自动copy到相应的文件夹，就不会出现jar包丢失的问题。

主要介绍JavaEE中Maven Web 项目的结构及其它几个小问题