在研究cas的过程中， 发现cas的部署项目是采用overlay方式部署的， 因此上网查找如下：

在一个大项目中拆分maven工程时，很有可能会把js、css、jsp等文件放在不同的工程里（根据业务模块划分）。因为如果都集中在一个maven webapp里，那么这个maven webapp会太大，而且在业务上也比较分散

但是这些持有js、css、jsp的maven工程，如果packaging设置为jar是不合适的，因为外围要读取内部的这些文件就会很困难。在这种场景下，一个很自然的想法就是打成war包，然后用某种方式将多个war包归并起来，得到最终的war包

这就是overlays发挥作用的地方

以下举一个例子：

这里有2个web工程，一个是task-sla-web，一个是task-web-dist，packaging类型都是war，目录结构如下：

下面是task-sla-web的pom文件：
Xml代码 收藏代码
<modelVersion>4.0.0</modelVersion>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>task-sla-web</name>

该工程就是打成一个war包，但是这个war是无法运行的，而是稍后用来合并的。（其中放了 一个空的web.xml，因为maven-war-plugin的package goal有强制要求）

下面是task-web-dist的pom文件：
Xml代码 收藏代码
<modelVersion>4.0.0</modelVersion>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-web-dist</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>task-web-dist</name>

Xml代码 收藏代码
<!– 合并多个war –>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<overlays>
<overlay>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>

Xml代码 收藏代码
<!– 配置依赖 –>
<dependencies>
<dependency>
<groupId>com.huawei.inoc.wfm.task</groupId>
<artifactId>task-sla-web</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>war</type>
</dependency>
</dependencies>

以上片段主要要注意几点：

1、task-web-dist自身的packaging类型也是war
2、在<overlay>中配置要归并的webapp的groupId和artifactId，注意的是，该pom所在的webapp工程是主工程，会覆盖掉所有待归并工程的同名文件，包括web.xml
3、要归并的webapp，必须声明为依赖

归并后的最终war包如下：

其中的文件和.class都是由2个war包归并得到的，task-web-dist是主war包，如果多个war包中存在重名文件，则会被task-web-dist的文件覆盖，比如web.xml

此部分来源： http://kyfxbl.iteye.com/blog/1678121

上述说明了 overlay的使用方法， 下面是 cas的overlay的资料

还好，maven的overlay的功能，可以帮助我解决这个问题。

什么是maven的overlay？
overlay可以把多个项目war合并成为一个项目，并且如果项目存在同名文件，那么主项目中的文件将覆盖掉其他项目的同名文件。
于是，我就可以完全不修改cas-server-webapp的原有代码实现CAS了。
步骤一：新建my-cas-server
默认的CAS是以cas-server-webapp为主项目，用户登录认证入口、用户登录页面、各种主配置文件都包含在此项目中。
现在，我把新建的my-cas-server作为我的主项目，而把cas-server-core项目作为从属项目导入主项目中。
my-cas-server的pom.xml
<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<version>3.4.11</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
步骤二：设置overlays
配置overlay用于覆盖从属项目的同名文件，意思就是说，如果我主项目中存在与cas-server-webapp项目相同目录并且相同名称的文件，已主项目的为准，也就是覆盖从属项目的文件。
在my-cas-server的pom.xml中添加：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
</plugins>
</build>
步骤三：拷贝同名文件
把之前修改过的cas-server-webapp的源码以及配置文件，全都列举出来，并且拷贝到my-cas-server的相同目录下。
例如：之前我改过了这么些代码(部分代码)
UsernamePasswordCredentials.java
AuthenticationViaFormAction.java
webapp/WEB-INF/
|–classes
|—cas-theme-default.properties
|—default_views.properties
|—messages_zh_CN.properties
|–spring-configuration
|—-ticketRegistry.xml
cas-servlet.xml
deployerConfigContext.xml
login-webflow.xml
web.xml

同样的，我把这些文件全部复制到新项目中，目录与原项目保持一致。
步骤四：启动my-cas-server测试效果
启动后发现，与之前效果完全一致，可以正常访问，也可以正常的进行认证。
扩展：
采用overlay方式后，不仅可以不用修改源码进行CAS改造，而且你还会发现，编码的自由度大大增加了，不用再受限于原有项目的种种约束。
例如，我想要美化一下登录页面，原有的太过简单了。
我完全可以像平时开发一下，重新绘制一个登录页面，然后在配置文件中替换掉默认登录页面就可以了。
然后修改一下default_views.properties
### Login view (/login)
casLoginView.(class)=org.springframework.web.servlet.view.JstlView
casLoginView.url=/WEB-INF/view/jsp/default/ui/casLoginView.jsp
–>
### Login view (/login)
casLoginView.(class)=org.springframework.web.servlet.view.JstlView
casLoginView.url=/WEB-INF/jsp/login.jsp
重新启动，运行。

此部分来源： https://www.cnblogs.com/notDog/p/5276645.html

另外，附上 cas的说明文档

WAR Overlay 安装

CAS的安装是基于源码的基础上构建出来的，我们建议你使用WAR overlay的方式来安装，可自动自定义安装，比如自行对组件的配置，和UI的设计；构建出来的是cas.war文件，该文件可以直接部署到servlet容器中，比如 Apache Tomcat。

安装要求

请参阅本指南了解更多信息。

War Overlay是什么？

Overlays是一种避免重复代码或重复资源的打包策略，它可以让你自行下载CAS预编译的应用后，自定义增加或者替换相应的配置和特性。在构建的时候，Maven/Gradle首先会自动下载更新安装，然后找到你的配置文件和设置，自动合并到你自动下载的目录结构中，来构建出一个完整的项目 (比如 cas.war)。重写或覆盖的文件包括资源文件、Java的classes文件、图像文件、CSS和JS文件。
为了合并过程的成功执行，本地重写或覆盖的文件的位置和名称，必须与之前下载的存档中的项目所提供的位置和名称完全一样。

虽然前面的方法可能稍微复杂，但这种方法有显著的优势：

1. 不需要从源站下载源码编译。
2. 在大多数情况下，通过简单地调整生成脚本，来下载更新的CAS版本，升级非常容易。
3. 与部署整个软件源代码不同的是，作为部署器，您只保留自己的本地定制，这使得更改跟踪变得更加容易。
4. 源代码修改的管理和跟踪非常轻量级，配置更改只要管理修改的部分（而不是整个软件），非常的简单。

管理 Overlays

CAS的各个部分都可以通过在Overlay中新增、删除和修改文件来控制；也可以通过增加第三方组件来自定义CAS的行为。

使用覆盖的过程，无论是Maven还是Gradle，都可以概括为以下步骤：

• 以构建/部署包为基础，开始构建
• 从生成的版本中识别需要更改的工件。这些工件通常是由Maven或Gradle中的目标或生成目录生成的。
• 将已识别的文件从复制到src目录。
  1. 创建src目录和所有的子目录，如果它们不存在的话。
  2. 复制的路径和文件名必须与它们的构建对应物完全匹配，否则更改不会生效。请参阅下表，了解如何将文件夹和文件从生成映射到src。
• 更改之后，尽可能多次重建并重复该过程。
• 请仔细检查内置二进制文件的更改，以确保覆盖过程正常工作。

CAS WAR Overlays

CAS WAR overlay项目供参考和学习。

要构造overlays的项目，需要在生成目录中把自定义的目录和文件复制到源目录。

在重新编辑文件之前，overlay的gradle工具可以提供额外任务，来生成二进制的项目；您可能需要手动完成这一步骤，以了解需要复制哪些文件/目录到源目录。

注意： 不要在上面提到的构建目录中做任何更改。每次构建时，更改将被除并设置为默认值。在源目录和/或其他指示的位置内放置重叠的组件以避免意外。

CAS Configuration Server Overlay

有关更多细节，请参阅Maven WAR overlay。

若要了解配置服务器的更多信息，请查看此指南。

Docker化部署

更多信息请参阅本指南。

Servlet容器

CAS可以部署到多个servlet容器中。更多信息请参阅本指南。

定制和第三方源

这是常见的定制或开发java组件，实现CAS API或包括由Maven依赖引用第三方源扩展CAS的功能。简单地在覆盖pom.xml或build.gradle文件。为自定义的java源码，Overlay项目应包括src/main/java目录。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

├── src
│   ├── main
│   │   ├── java
│   │   │   └── edu
│   │   │       └── sso
│   │   │           └── middleware
│   │   │               └── cas
│   │   │                   ├── audit
│   │   │                   │   ├── CompactSlf4jAuditTrailManager.java
│   │   │                   ├── authentication
│   │   │                   │   └── principal
│   │   │                   │       └── UsernamePasswordCredentialsToPrincipalResolver.java
│   │   │                   ├── services
│   │   │                   │   └── JsonServiceRegistryDao.java
│   │   │                   ├── util
│   │   │                   │   └── X509Helper.java
│   │   │                   └── web
│   │   │                       ├── HelpController.java
│   │   │                       ├── flow
│   │   │                       │   ├── AbstractForgottenCredentialAction.java
│   │   │                       └── util
│   │   │                           ├── ProtocolParameterAuthority.java

Maven 警告

另外，请注意，任何自定义的java组件编译要包含在最终的cas.war文件，Overlay项目中的Maven pom.xml必须包含Maven的java编译器，这样可以编译的java类。

以下是Maven构建配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

...

<build>
    <plugins>
...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>${java.source.version}</source>
                <target>${java.target.version}</target>
            </configuration>
        </plugin>
...
    </plugins>
    <finalName>cas</finalName>
</build>

依赖管理

CAS的每个版本都提供了它支持的依赖列表。在实践中，您不需要为构建配置中的任何依赖项提供一个版本，因为CAS发行版正在为您管理这些版本。当升级CAS本身时，这些依赖性也将以一致的方式升级。

这个依赖列表包含第三方库的组件。这个列表可以作为标准物料清单（BOM）。

若要将项目配置为从BOM继承，只需设置父级：

Maven

1
2
3
4
5

<parent>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-support-bom</artifactId>
    <version>${cas.version}</version>
</parent>

并不是每个人都喜欢从BOM继承。您可能需要使用自己的企业标准父级，或者可能更喜欢显式声明所有Maven配置。

如果不想使用cas-server-support-bom，仍然可以通过使用scope=import，得到依赖组件管理的好处（不是插件管理）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<dependencyManagement>
     <dependencies>

        <!-- Override a dependency by including it BEFORE the BOM -->
        <dependency>
            <groupId>org.group</groupId>
            <artifactId>artifact-name</artifactId>
            <version>X.Y.Z</version>
        </dependency>

        <dependency>
            <groupId>org.apereo.cas</groupId>
            <artifactId>cas-server-support-bom</artifactId>
            <version>${cas.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Gradle

使用Gradle来使用CAS BOM，请使用此指南，并相应配置Gradle构建。

_{(1) WAR Overlays}