Maven之GroupId、ArtifactID等

pom.xml

<groupId>com.yucong.commonmaven</groupId> 
<artifactId>commonmaven</artifactId> 
<version>0.0.1-SNAPSHOT</version> 
<packaging>jar</packaging> 
<name>common_maven</name> 

1. groupId
   中文解释：项目包名 。是项目组织唯一的标识符，实际对应JAVA的包的结构，是main目录里java的目录结构。
   定义了项目属于哪个组，举个例子，如果你的公司是mycom，有一个项目为myapp，那么groupId就应该是com.mycom.myapp.
2. artifactId
   中文解释：工程名，子项目（模块）标识。是项目的唯一的标识符，实际对应项目的名称，就是项目根目录的名称。定义了当前maven项目在组中唯一的ID,比如，myapp-util,myapp-domain,myapp-web等
3. version
   指定了myapp项目的当前版本，SNAPSHOT意为快照，说明该项目还处于开发中，是不稳定的版本
4. name
   声明了一个对于用户更为友好的项目名称，不是必须的，推荐为每个pom声明name，以方便信息交流。
5. packaging
   中文解释：打包方式。当不定义packaging时，maven会使用默认值jar。

pom.xml 依赖配置,可以去https://mvnrepository.com/查找所需要依赖配置
maven module和project的区别

• Maven Project可以理解为父工程，是最上级的项目，一般没有其他parent项目。
• Maven Module可以理解为子工程，就是为了继承，引用父项目而建的。
• 创建Maven Module工程必须有存在的父工程，maven就是通过父子工程进行工程管理的。

maven 配置多模块项目 pom modules

• 所有用Maven管理的真实的项目都应该是分模块的，每个模块都对应着一个pom.xml。它们之间通过继承和聚合（也称作多模块，multi-module）相互关联。那么，为什么要这么做呢？我们明明在开发一个项目，划分模块后，导入Eclipse变成了N个项目，这会带来复杂度，给开发带来不便。

• 为了解释原因，假设有这样一个项目，很常见的Java Web应用。在这个应用中，我们分了几层：
  Dao层负责数据库交互，封装了Hibernate交互的类。
  Service层处理业务逻辑，放一些Service接口和实现相关的Bean。
  Web层负责与客户端交互，主要有一些Structs的Action类。
  对应的，在一个项目中，我们会看到一些包名：
  •org.myorg.app.dao
  •org.myorg.app.service
  •org.myorg.app.web
  •org.myorg.app.util

• 这样整个项目的框架就清晰了，但随着项目的进行，你可能会遇到如下问题：

  1.这个应用可能需要有一个前台和一个后台管理端（web或者swing），你发现大部分dao，一些service，和大部分util是在两个应用中可。这样的问题，你一周内遇到了好几次。

  2.pom.xml中的依赖列表越来越长以重用的，但是，由于目前只有一个项目（WAR），你不得不新建一个项目依赖这个WAR，这变得非常的恶心，因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，而且你根本不需要org.myorg.app.web。有人修改了dao，提交到svn并且不小心导致build失败了，你在编写service的代码，发现编译不过，只能等那人把dao修复了，你才能继续进行，很多人都在修改，到后来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引入。甚至出现了一个依赖有多个版本存在。

  3.build整个项目的时间越来越长，尽管你只是一直在web层工作，但你不得不build整个项目。

  4.某个模块，比如util，你只想让一些经验丰富的人来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不能达到你的要求。

• 我们会发现，其实这里实际上没有遵守一个设计模式原则：“高内聚，低耦合”。虽然我们通过包名划分了层次，并且你还会说，这些包的依赖都是单向的，没有包的环依赖。这很好，但还不够，因为就构建层次来说，所有东西都被耦合在一起了。因此我们需要使用Maven划分模块。

• 一个简单的Maven模块结构是这样的：
  —- app-parent

        |– pom.xml (pom)
  
        |
  
        |– app-util
  
        |        |– pom.xml (jar)
  
        |
  
        |– app-dao
  
        |        |– pom.xml (jar)
  
        |
  
        |– app-service
  
        |        |– pom.xml (jar)
  
        |
  
        |– app-web
  
                 |– pom.xml (war)   
  

上述简单示意图中，有一个父项目(app-parent)聚合很多子项目（app-util, app-dao, app-service, app-web）。每个项目，不管是父子，都含有一个pom.xml文件。而且要注意的是，小括号中标出了每个项目的打包类型。父项目是pom,也只能是pom。子项目有jar，或者war。根据它包含的内容具体考虑。
这些模块的依赖关系如下：

app-dao –> app-util

app-service –> app-dao

app-web –> app-service

注意依赖的传递性（大部分情况是传递的，除非你配置了特殊的依赖scope），app-dao依赖于app-util，app-service依赖于app-dao，于是app-service也依赖于app-util。同理，app-web依赖于app-dao,app-util。

用项目层次的划分替代包层次的划分能给我们带来如下好处：
1.方便重用，如果你有一个新的swing项目需要用到app-dao和app-service，添加对它们的依赖即可，你不再需要去依赖一个WAR。而有些模块，如app-util，完全可以渐渐进化成公司的一份基础工具类库，供所有项目使用。这是模块化最重要的一个目的。
2.由于你现在划分了模块，每个模块的配置都在各自的pom.xml里，不用再到一个混乱的纷繁复杂的总的POM中寻找自己的配置。
3.如果你只是在app-dao上工作，你不再需要build整个项目，只要在app-dao目录运行mvn命令进行build即可，这样可以节省时间，尤其是当项目越来越复杂，build越来越耗时后。
4.某些模块，如app-util被所有人依赖，但你不想给所有人修改，现在你完全可以从这个项目结构出来，做成另外一个项目，svn只给特定的人访问，但仍提供jar给别人使用。
5.多模块的Maven项目结构支持一些Maven的更有趣的特性（如DepencencyManagement），这留作以后讨论。
maven 配置多模块项目 pom modules参考网址：https://blog.csdn.net/linhao19891124/article/details/73872303