WebJars资源
WebJars官网地址:
搭建WebJars的官方文档:
使用WebJars官方文档:
下载WebJars的Maven插件地址:
公共的CDN地址:
我的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文件源码: