Maven在日常应该是用得挺多的,毕竟我们都需要打包发布上线的嘛,但是刚毕业的时候可没有这个概念。
我们肯定是知道Maven能管理我们的项目,但是在学习的时候往往只用到Maven来导入各种的依赖。
我们肯定是知道Maven是有对应的仓库,然后我们配置了国内的Maven仓库来让jar包下载得更快。
我们可能会用Maven来编译自己的项目,本地打好package,然后将项目在本地启动起来。如果我们有一台机器的服务器,打完包以后就将本地的war包手动上传到自己的服务器上启动。
我们可能会知道Maven可以配置自己的仓库(私有仓库),可能会搭建过,但是又有哪几个人将自己的jar包发布到私有的仓库呢?
去到公司里边,公司一般也有自己的私有仓库,我们写的系统可能会被各个团队使用的,所以我们会把写好的包打到私有仓库上。常用到的Maven命令其实不会很多,一般就是以下的几个:
1、mvn compile
2、mvn test
3、mvn clean
4、mvn pakage
5、mvn install
6、mvn deploy
7、mvn versions:set -DnewVersion=xxxx 设置Maven的版本
8、mvn dependency:tree 查看maven的依赖树(排查依赖很有效)
常用参数
-Dmaven.test.skip=true
-Dmaven.JAVAdoc.skip=true
直接从网上摘录以下package、install、deploy的区别:
一个工程下一般也会有多个Module,我们会用父工程的pom.xml来管理我们的jar包版本,在子Module引用父工程的就好了。
别傻乎乎地就将各种jar包的版本到子Module下写,虽然jar包是肯定能导入进去了,但是这样做不规范。
下面简单体验几个最常用的命令(建议自己实操一下)
mvn compile -Dmaven.test.skip=true,这个命令会把我们的代码编译,编译完我们如果使用IDEA就可以发现有target目录
mvn package -Dmaven.test.skip=true就可以帮我们打包。
最近三歪在整合系统,把一些零散的系统整合到一个系统里边,所以一个系统会出现多个Module。之前项目也是多个Module的,只是没有现在的多,比如下面的图
从上面的图我们可以看到在父工程下有几个配置文件,分别是dev/local/online/pre。很明显地,我们不同的环境下,配置应该是不一样的。
这应该很好理解,我们线上的服务器配置信息和测试环境的配置信息怎么可能相同嘛,所以各个环境的配置是分开的。
因为要做合并的事,我就把一些系统合并到父工程里边去。所以我会在父工程下新建Module,然后把代码拷贝进去。显然,每个工程可能都会有相应的配置,然后配置也是区分环境的嘛。
比如下面的图(sanwai.name这份配置由各个环境下的配置所去读取):
我在各个环境下的配置文件都写好了sanwai.name的值了
等我一切写完的时候,我发现服务一直启动不起来,始终没有读到我在dev/local/pre/online配置的值。我就很怀疑了,明明我配置了呀。
Spring的property-placeholder我明明都已经写好了,路径都没有任何问题,在本地都能直接「点」去跳转到对应的配置文件了。这咋回事啊
<context:property-placeholder
ignore-unresolvable="true" ignore-resource-not-found="true"
location="classpath*:core-config.properties" />
于是,我花了很长的一段时间上看我的property-placeholder是不是有问题,是不是我哪里的使用姿势不对。
最后实在忍不住了,问了一下同事有没有遇到过这个坑,然后同事告诉我:分环境读取配置不是Spring的功能,是Maven
我:????然后在内网搜了一下,还真的是。大概看了一下,其实就是用到了Maven的profile功能。
后来在pom文件下指定读取对应的配置文件路径,就可以了。
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering><!-- 是否使用过滤器 -->
</resource>
</resources>
</build>
其实就是在打包的时候去指定不同的环境,从而生成一份正确的配置文件。
mvn clean package -DskipTests -Ptest // 指定的是test环境
那么按道理,只要我发布上线过代码,就应该知道有这么一个东西啊。
我司有自己的一套发布系统,把很多的细节都给屏蔽掉了(无论是Git还是Maven的细节都屏蔽了很多)。压根就不需要自己去打命令去创建Git分支,去合并master分支,去敲maven的命令打包。
本书适合所有Java程序员阅读。由于自动化构建,依赖管理等问题并不只存在于Java世界,因此非Java 程序员也能够从该书中获益。无论你是从未接触过Maven、还是已经用了Meven很长时间,亦或者想要扩展Maven,都能从本书获得有价值的参考建议。
其次,本书也适合项目经理阅读,它能帮助你更规范、更高效地管理Java项目。
第1章对Maven做了简要介绍,通过-些程序员熟悉的例子介绍了Maven 是什么,为.什么需要Maven.建议所有读者都阅读以获得一个大局的印象。
第2-3章是对Maven的一个人门介绍,这些内容对初学者很有帮助,如果你已经比较熟悉Maven,可以跳过。
第4章介绍了本书使用的背景案例,后面的很多章节都会基于该案例展开,因此建议读者至少简单浏览一遍。
第5-8章深人阐述了Maven 的核心概念,包括坐标,依赖、仓库。生命周期、插件,继承和多模块聚合,等等,每个知识点都有实际的案例相佐,建议读者仔细阅读。
第9章介绍使用Nexus建立私服,如果你要在实际工.作中使用Maven,这是必不可少的。
第10-16章介绍了一些相对高级且离散的知识点,包括测试,持续集成与Hudon, Web项目与自动化部署、自动化版本管理、智能适应环境差异的灵活构建、站点生成,以及Maven的Eelipse插件m2elipe,等等。读者可以根据自己实际需要和兴趣选择性地阅读。
第17-18章介绍了如何编写Archeype和Maven插件。一般的Maven用户在实际工作中往往不需要接触这些知识,如果你需要编写插件扩展Maven,或者需要编写Archetype维护自己的项目骨架以方便团队开发,那么可以仔细阅读这两章的内容。