Learning notes: Maven constructs the version number to solve the browser cache problem, learning notes maven

Learning notes: Maven constructs the version number to solve the browser cache problem, learning notes maven
Problems to be Solved

During WEB system development, in order to improve the performance, the browser's cache function will be used. In fact, even if the explicit declarative cache is not used, modern browsers will apply static files (js, css, images, and so on) cache. But it is also because of this problem that the cache logic of resources sometimes becomes faulty and the latest Server File cannot update the client cache.

This problem will cause a lot of troubles to users. Of course, the first problem is that testers have a headache. Why do developers need to do well with bugs that do not seem to have been fixed? In this case, I can say: ctrl + f5 refresh. However, this is not a solution.

Thoughts and methods

I have not dealt with such a problem before, but I know that the cache can be solved through timestamps and version stamps. To put it bluntly, the browser will naturally download the latest version of The link url, which is not easy to think about. If the project is too tight, the problem will not be taken seriously. Wait for time to solve the problem.

Now, we have time to start solving the problem. I found a lot of methods and found that it can be solved simply by adding a version number/timestamp:

<link rel="stylesheet" type="text/css" href="/css/common.css?ver=${sysVersion}" />

In the above Code,? Ver =$ {sysVersion}

Note: The project uses velocity, so $ {sysVersion} refers to the variable in velocity.

New Problems

However, a new problem arises. We use hudsun + maven to construct, automatically release, and deploy the Service on the web server. So how do we add a version stamp during maven construction?

Method

Finally, I chose the first method because I did not solve T_T in integrating the front-end compilation tool. The reason is:

1. F. I .S needs to be based on Node. js. This requires many configuration items, which is a bit of a hassle. When I set up my own environment, I tried it for many days. Later I found it was caused by the Network wall.

2. In addition, because the project is not very standardized, F. I .S requires a lot of code to be changed during generation. This is something that I am not willing to do.

 

Therefore, the solution is implemented in a simple way, and the configuration is completed in the last day.

Use the simplest single version number

A single version makes it easy to solve the problem. You only need to generate a version number at the time of release, whether it is time, number, or something else, all resources can reference this version number. Find a maven plug-in: maven-svn-revision-number-plugin. This plug-in can obtain the svn version number and use it as the build number, the advantage is that a new version will be generated when code is submitted. The plug-in code is as follows:

<Plugin> <groupId> com. google. code. maven-svn-revision-number-plugin in </groupId> <artifactId> maven-svn-revision-number-plugin </artifactId> <version> 1.7 </version> <configuration> <verbose> true </verbose> <entries> <entry> <prefix> prefix </prefix> <! -- Version stamp prefix --> <depth> empty </depth> </entry> </entries> </configuration> <executions> <execution> <phase> validate </phase> <! -- Lifecycle stage --> <goals> <goal> revision </goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId> org. tmatesoft. svnkit </groupId> <! -- Because svn1.8 is used, therefore, you need to rely on this plug-in --> <artifactId> svnkit </artifactId> <version> 1.8.9 </version> </dependency> </dependencies> </plugin>

This plug-in is used to obtain the latest svn version number during maven construction, and then use the filtering of maven resources to apply variables in various configuration files. In this way, the version number is written into the file during the construction.

Resources Code:

<Resources> <resource> <directory> src/main/resources </directory> <includes> <include> **. properties </include> <! -- Only process the properties file --> </program des> <filtering> true </filtering> <! -- Enable variable embedding --> </resource> <directory> src/main/resources </directory> <excludes> <exclude> **. properties </exclude> </excludes> <filtering> false </filtering> </resource> </resources>

Because the properties file is used as the carrier, the above setting is to find the properties file and write the version number. I created a build_version.properties file and wrote a setting item:

build.version=${prefix.committedRevision}

You can get the version number generated by the maven-svn-revision-number-plugin plug-in by $ {prefix. committedRevision.

After the settings are completed, you can see the effect by using Maven install. After the construction, find the build_version.properties file in the target directory to view the content:

build.version=114912

Then it becomes a number.

 

Let's take a look at the variables that will be generated in the maven-svn-revision-number-plugin plug-in:

[INFO] --- maven-svn-revision-number-plugin:1.7:revision (default) @ zrtc ---[INFO] inspecting E:\workspace\web[INFO]   prefix = prefix[INFO]   depth = empty[INFO]   report unversioned = true[INFO]   report ignored = false[INFO]   report out-of-date = false[INFO]  collecting status information[INFO]       114969 114912 E:\workspace\web[INFO]  setting properties[INFO]   prefix.repository = [INFO]   prefix.path = [INFO]   prefix.revision = 114969[INFO]   prefix.mixedRevisions = false[INFO]   prefix.committedRevision = 114912[INFO]   prefix.committedDate = 2015-10-23 09:03:39 +0800 (Fri, 23 Oct 2015)[INFO]   prefix.status = [INFO]   prefix.specialStatus = 

The plug-in has several variables.CommittedRevisionThis is the last version submitted by the Project svn directory.RevisionThe latest version number of svn. Prefix. needs to be added when using other files. This is defined in the configuration file. You can refer to the above configuration content.

<Prefix> prefix </prefix> <! -- Version stamp prefix -->

You can name the prefix by yourself.

 

This feature solves the problem of resource version updates. Look at the browser front-end page source code:

<link rel="stylesheet" href="/css/h_login.css?ver=114912" type="text/css">

 

Future Goals

Recently, we have seen some better methods to solve the problem of front-end client resource updates, such as front-end engineering build tools such as F. I .S. In the process of understanding, I learned a front-end engineering concept, which is somewhat big, but it is indeed a development trend in the future. In the more and more in-depth development of B/S, the development platform browser + server has proved its superiority, and mobile Internet and cloud computing have all reflected this development trend. Browser is the most widely used software in the past 10 years, right? Moreover, the browser has proved that it is omnipotent. Based on HTML + CSS, it can implement numerous beautiful interfaces. The common commercial systems have also been moved to the B/S architecture. It can be seen that HTML is a great development platform.

Is it a little outdated if you cannot do things related to the Times? Therefore, in the future, we need to think about the modularization of the front-end system and ultimately implement engineering.