之前敖丙写完了代码以后,我让他打包,然后我在工程里引用一下。过了一阵子,他传了一个本地jar
包给我。
三歪:「你给我个本地jar包干什么啊?」
敖丙:「你让我打的包啊」。
三歪:????你怎么打的包啊。
敖丙:就mvn package
啊,有问题吗?
三歪:我要的是pom
依赖,不是本地的jar
包
敖丙:这怎么弄的?教教我
然后三歪就手把手教学如何使用mvn deploy -Dmaven.test.skip
我好久之前也买了《Maven实战》这本书,当时翻了前面的一些章节,发现读不进去了。心想:“这有什么好看的?”
然后三歪就是被Maven各种吊打了,没有好好学习的下场就是报错连错在哪儿都不知道。
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的命令打包。
可以发现的是,我们自己在玩的,跟企业在用的还是有点差距的。我们自己写的项目不会分这么多环境,所以我们很可能就用不到maven的profile
功能。我们自己写的项目不会发到Maven私服
中,但每个公司几乎都有自己的一个Maven服务器。
其实说这么多,还是三歪之前没有好好看书导致的,我就不掩饰了,我是个菜鸡。
我在初学的时候写过一篇Maven的入门文章,如果还不了解Maven的同学可戳:Maven就是这么简单
更多的Maven命令:https://www.cnblogs.com/shoshana-kong/p/11031388.html