Maven的overlay插件的用法【结合cas4.0.3】
overlay插件是用户多个web项目的war包合并,被依赖的war包会根据pom中的配置以及主项目的现有文件进行合并。用途:1.大型web项目的并行开发。在分布式的趋势下,这个用途应该不多了。2.基于他人项目的修改,比如:cas本身用来做登陆权限的中央认证,其中项目源码非常之多,但本身必须是一个持续运行在服务器上的web项目,对于开发者而言只是需要在cas代码上根据业务做一些修改,涉及到的文件可能只有三四个,而其他多余的东西完全用不到,这就会导致项目看起来十分累赘、冗余。时间一久也忘了几十上百个文件中到底修改了那些。
而使用overlay插件的好处在于:1.项目看起来更加清爽。2.因为项目中的已有的文件就是自己定义的文件,即使是后面接手的人,也一目了然、便于维护。3.提高开发效率,若用传统方式需要提取所以文件到项目,一旦漏掉哪个就会导致报错,编写代码也不会因为代码文件太多太庞大,导致编译工具卡顿,最终运行的版本会在项目运行时先合并再编译运行。
以cas4.0.3为例,左边传统方式,右边使用overlay插件
可以看出项目立即变得清爽,需要自定义什么内容,只需要在项目中创建对应目录结构下的同名文件即可。
overlay插件的用法
1.首先创建一个干净清爽的maven webapp项目
2.打开pom文件加入overlay的插件
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
其中<overlays>
标签下可以加入多个<overlay>
也就是支持多个war包的合并,填写时只需写入<groupId>
和<artifactId>
不需要版本号。
3.将overlay
里面的war包依赖加入到dependencies
中:
dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<version>4.0.3</version>
<type>war</type>
<!--<scope>runtime</scope>-->
</dependency>
scope
写不写都一样,因为在编写代码时候,获取不到war中的jar包依赖。
4.此时项目中会多一个overlay的文件:
需要修改什么内容,则参照overlay里面的结构去创建同样的目录和文件即可,这里需要将overlay里面的web.xml文件复制到主项目中,因为合并后的内容都是以主项目的文件为准,而web.xml是整个webapp的核心配置文件,因此在无法被覆盖的前提下,要保证主项目的web.xml包含了所有overlay项目中的web.xml的启动配置环境,如各种filter和spring的配置文件的扫描路径是通用的
5.将web.xml提取到主项目中替换后,即可直接在tomcat中启动起来
同时关注到项目运行时,生成的target文件:
发现overlay
下面的文件都最终合并在主项目中。
6.自定义一个登陆界面
cas4.0中直接替换WEB-INF/view/jsp/default/ui/casLoginView.jsp
即可完成对登陆界面的修改。
先创建一个同目录下的同名文件:
然后启动项目测试:
发现界面直接变成了自定义的,同时观察生成的target文件:
发现此时的casLoginView.jsp
自动变成了自定义的。
7.includes
与excludes
的用法
打开生成的target文件:
发现unused-spring-configuration文件下的东西完全不需要的,此时在pom的<overlay>
下做如下修改:
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<excludes>
<exclude>WEB-INF/unused-spring-configuration/**</exclude>
</excludes>
</overlay>
</overlays>
然后将target删除后,再启动项目:
发现被exclude
匹配的文件直接消失。
总结:<overlay>
下的<exclude>
下匹配的文件不会出现在最终合并target中,也就是启动环境中去。这个可以用于一些主项目用不到的资源文件可以用exclude
直接移除掉。
那么对应的include
则代表只将include
中匹配的文件合并到主项目中去。同样的来做个测试:
- 这次只加载overlay中的jsp进来:
pom:
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<includes>
<include>WEB-INF/view/jsp/**</include>
</includes>
</overlay>
- 删除target文件,运行后发现:
这次只有jsp文件被合并了进来。
总结:<overlay>
下若有<include>
的配置,则最终合并的文件只包含include下匹配的文件
include用于让开发者去灵活选择overlay中只需要用到的资源。
8.dependentWarIncludes
与dependentWarExcludes
这两个和include
与exclude
用法一致,前者配置只合并的文件,后者配置不合并的文件。那么和include
与exclude
的区别是啥呢?
先看pom用法:
<configuration>
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<includes>
<include>WEB-INF/view/jsp/**</include>
</includes>
</overlay>
</overlays>
<!--<dependentWarIncludes>WEB-INF/web.xml</dependentWarIncludes>-->
<dependentWarIncludes>WEB-INF/**</dependentWarIncludes>
<dependentWarExcludes>WEB-INF/view/jsp/default/ui/casLogoutView.jsp</dependentWarExcludes>
</configuration>
可以看到用法是直接写在configuration
节点下,也就是说,这个配置对所有overlay
都起作用,前提是<overlay>
下没有<include>
与<exclude>
,也就是说<dependentWarIncludes>
和<dependentWarExcludes>
是全局作用,每个<overlay>
下的war包都会被应用到该配置,但是优先级要低于<include>
与<exclude>
。