客户端web库——WebJars

WebJars资源

WebJars官网地址：

• WebJars官网

搭建WebJars的官方文档：

• 搭建WebJars官方文档

使用WebJars官方文档：

• 使用WebJars官方文档

下载WebJars的Maven插件地址：

• 下载WebJarsMaven插件

公共的CDN地址：

• jsDelivr – Open Source CDN

我的image-cut开源项目示例：

• image-cut

WebJars简介

WebJars的特点：

• 在基于jvm的web应用程序中显式地管理客户端依赖关系

• 使用基于jvm的构建工具(如Maven、Gradle、sbt、…)来下载您的客户端依赖项

• 了解您使用的客户端依赖关系

• 传递依赖项会自动解析并可选地通过RequireJS加载

• 部署在Maven中央仓库

• 公共CDN由jsDelivr提供。

为什么要使用WebJars

传统的Web资源管理方式：

现在的Javaweb项目大都是采用的Maven架构，在开发项目时，我们往往会将一个大项目拆分成许多分散的Maven模块，每个模块实现该项目的某一部分功能，当我们将各个模块开发完毕之后，直接将其组装到一起即可构成一个大的完整项目。

它的优点：

• 由于将一个大项目拆分成众多的小模块，这样大大降低了程序开发的难度。

• 由于模块与模块间很多组件都是可以多个项目共用的，这样就降低了所要编写的代码量，提高了代码开发的速度与质量。

• 不同的Maven模块都是有不同的版本号，我们可以通过对版本号的管理，方便程序后续的管理和升级。

它的缺点：

  由于现在的项目是由众多的Maven模块组成的，其中含有Web前端资源的Maven就不在少数，而这些含有前端资源，比如说JS或CSS，诸如jQuery或者Bootstrap等的管理就成为了一个大问题。

  比如说通过人工的方式进行管理，这可能会产生版本号误差，拷贝版本错误，漏拷贝等诸多现象，而一旦该现象产生，那么导致前端页面无法正确显示，版本混乱，而且这样的错误往往会表现出一些莫名其妙的故障，导致后期的纠错也相当的麻烦。毕竟前端的开发人员往往不懂后端的程序和框架，诸如Java，Spring，Maven之类的；而后端的开发人员也不清楚前端到底是个什么情况，是bug?是版本错误？是文件混乱？还是设计如此，留待后期完善？等麻烦不断。

WebJars的优点

  而我们采用WebJars的优点就是可以借助Maven工具，以jar包的形式，通过对Web前端资源进行统一依赖管理，保证这些Web资源版本的唯一性。

创建WebJars项目

WebJars的jar文件结构

  在看WebJars的jar文件结构时，我们以用途最广泛的jquery的WebJars为例来说明。如下就是jquery-3.2.1.jar的文件目录结构。

META-INF
    └─maven
        └─org.webjars.bower
            └─jquery
                └─pom.properties
                └─pom.xml
    └─resources
        └─webjars
            └─jquery
                └─3.2.1
                    └─（这里是静态资源文件）

WebJars的静态资源文件存放位置

  从上面的文件结构可以看出，WebJars的静态资源存放位置与普通的Javaweb静态资源的存放位置是不同的，普通的Javaweb项目的静态资源文件往往是存放在webapp文件目录下，而当我们要将静态资源打进jar包时，我们就得采用WebJars的静态资源存放原则，那就是将静态资源文件存放到src.main.resources.META-INF.resources.webjars目录下。如下是我所创建的image-cut项目，该项目就是采用的WebJars的格式进行的封装。

WebJars必须遵守的命名规范

• WebJar的内容的路径必须是如下格式：

META-INF/resources/webjars/${name}/${version}

  该格式是由WebJars官网明文规定的，是必须要遵守的规范格式。之所以选择这个路径结构，是因为它可以得到Java Web框架的广泛支持，并且包含路径中的版本号，因此可以很容易地使用具有侵略性的缓存。

• 版本号必须在WebJar路径中，而不是在文件中。

• 版本号是上游版本，而不是WebJar版本。大多数情况下，这些都是一样的。但有时，WebJar中有一些包装错误，只会在WebJar版本中造成一个版本的颠簸。

• 上游的源必须是一个版本化的工件。如果上游源没有提供发布版本，那么可以使用提交日期+git提交ID(例如。20140708-394bf29)或派生上游项目并应用语义版本控制。

• artifactId应该始终是小写的。它可以从(按优先顺序)构建：

创建pom.xml文件

  pom.xml文件源码：