Maven打包说明

Java代码从编码到最后运行到两个核心步骤为"编译"和"执行"。"编译"会根据"源代码"产出对应的".class"文件，而"执行"就是让程序运行起来，运行的对象就是这些".class"文件。

那么，“源代码”也好，“.class”文件也好被放到了哪里呢？目录结构是怎样的呢？

如图所示：“quark-net”是一个module的根目录，也就是工程目录。

“quark-net”的下一级有两个目录，一个是“src”，一个是“target”。简单的理解，“src”就是常规的“源代码”存在的最上级目录，而“target”就是“编译”后生成的文件位置的最上级目录。

“src”的下一级也有两个目录，一个是“main”，一个是“test”。简单的理解，“main”内是项目正式文件，而“test”内是项目测试文件。

“src/main”的下一级也有两个目录，一个是“java”，一个是“resources”。简单理解，“java”内就是项目源代码，而“resources”内是程序运行所需要的资源文件(一般以配置文件居多)。

“target”内部需要关注的就是“classes”目录，“src/main”内的文件编译后就是到“target/classes”内。

mvn clean install

以上命令为默认MAVEN打包的命令

使用该命令打包时，项目工程也会先被“编译”，“target/classes”下会有重新编译的内容。包括源代码编译后的“.class”文件，以及resources目录下的资源文件。

“编译”完成后，就会打包。所有“target/classes”下的内容会被打进最后形成的JAR包内（这也证明了JAVA程序的特点，一次编译，多处运行。因为JAR包内的文件已经是“编译”后的内容）。

这个用到了插件，需要先理解下述的配置以及原理

mvn clean package assembly:single

默认打包方式，最后会把“target/classes”内的所有文件放到JAR包内，包括resources下的文件。思考这样一个问题，如果resources里面有项目启动时的配置文件，那么如果我们在运行jar包的时候，想修改配置文件内的内容怎么办呢？按照默认打包方式，我们需要先修改配置文件，然后再重新打包，这样每一次对配置文件的修改，都依附于一次重新打包。此时，就需要有一种方法来支持所谓的“配置文件外置”的需求。

“编译”的时候会把“src/main”内的文件编译后放到“target/classes”下，打包会把“target/classes”下的文件放进JAR包。既然如此，想要实现“配置文件外置”的需求，就要找一种方式，让“src/main/resources”下的文件不被编译进“target/classes”下就可以了，这就需要用到项目pom文件中的“resource”标签了。

在pom文件中增加上述配置即可自定义指定编译后文件的存放位置。

上述配置之后，“src/main/resources”下的文件会被放到“target/resources”目录下。

此时再打包时，“target/classes”下就不会有“src/main/resources”的内容，那么对应的JAR包内也不会有这部分文件了。

此处只是用一个例子作为介绍，实际上理解了本质，pom中的该标签可以根据需求做出很多配置。此处不对该标签做过多的介绍，但其实际功能远不止此。

经过上述定制“编译”后，如果使用maven打包，JAR包内是不会有配置文件的(src/main/resources下的文件都不会有)。虽然解决了这个问题，但是此时直接执行JAR包，肯定无法运行，因为JAR包内没有了配置文件，那么程序也就找不到配置文件了。所以，需要一种方式，告诉JAR包，配置文件去哪里读取。这里，介绍使用MAVEN插件的方式，指定配置文件。

pom文件增加上述插件的配置，如图所标识的配置，就是告诉JAR包，你执行的时候去这个路径下读取配置文件，这个路径是相对于JAR包位置的路径。例子中配置的就是JAR包同级目录下的resources文件夹下去读配置文件。

该插件的其他配置可以参考注释，此处不做过多解释，只需要知道标注的位置告诉了JAR包读取配置文件的路径即可。

有了定制编译后，我们分离了JAR包和配置文件。有了定制打包后，我们告诉了JAR包读取外置配置文件的路径。思考一个问题，难道每次我们都要手动拷贝src/main/resources内的文件，然后放到JAR包同目录下的位置（也可以配置其他位置，此处以上述例子中的配置做介绍）吗？此时我们可以在打包的时候除了形成JAR包，同时也将其他我们想要的内容也进行打包，最后将这全部的内容全部打进一个整体的包内。此处还是介绍一种MAVEN插件的形式。

如图所示，pom中配置此插件，进行整体打包。

该插件需要assembly.xml的配置文件，如图标识为改配置文件的路径。

如上图所示，第一个标注为最终整体包的压缩方式，此处配置的是zip包。

而第二个标注就是将“src/main/resources”里的内容打进zip包的根目录的resources目录下。

fileSets中的第二个fileSet的配置是将JAR包也放到zip包的根目录下。至此，JAR包和外置配置文件的相对路径就形成了。

在进行上述的配置后，已经成功解决了“resources”资源文件外置的问题，这样只要打包一次后，每次运行的时候都可以修改配置文件，并且让修改后的配置文件生效了。但是，如果你真的这么配置了，当你在某些时候使用本地IDEA运行自己的工程代码的时候，会提示找不到配置文件的错误。

如果理解JAVA程序资源路径的配置这个问题就会很容易理解。如上图所示，我们程序中配置文件的路径可以直接使用相对路径，那么这个相对路径在使用ClassLoader去load的时候，其实就是target/calsses里面去找。也就是说，“.class”文件执行时候的相对位置的相对路径就是“target/classes”路径。图中直接在源代码中使用的配置文件虽然直接写的是“robot.properties”，但其实是“target/classes/robot.properties”，因为源代码编译后的路径是“target/classes”目录。

理解了JAVA程序资源路径的配置后，这个问题就会很容易理解。我们在pom中定制编译的时候重新指定了资源文件的位置，那么“target/classes”中已经没有了资源文件，自然就找不到了。

一种简单的解决方式，就是程序中写的路径，需要指定为pom中定制编译时重新指定的路径。另一种简单的方式是，每次本地IDEA编译执行的时候，将pom中标签注释掉，打包的时候再启用。无论是哪种方式都不太理想，这里提供一种新的思路。

该思路为，定制编译的时候还是将src/main/resources下的内容编译进target/classes中，这样保证了本地执行的时候可以找到配置文件。然后插件配置的时候使用includes标签，只将.class文件打进jar包，这样依然保证了JAR包内不会打进资源文件，然后资源文件仍旧是使用插件打进zip包内配置的相对路径下即可！