maven resource解释

2020年6月8日真三打老虎评论

Resources

Another feature of build elements is specifying where resources exist within your project. Resources are not (usually) code. They are not compiled, but are items meant to be bundled within your project or used for various other reasons, such as code generation.

For example, a Plexus project requires a configuration.xml file (which specifies component configurations to the container) to live within the META-INF/plexus directory. Although we could just as easily place this file within src/main/resources/META-INF/plexus, we want instead to give Plexus its own directory of src/main/plexus. In order for the JAR plugin to bundle the resource correctly, you would specify resources similar to the following:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <build>
    ...
    <resources>
      <resource>
        <targetPath>META-INF/plexus</targetPath>
        <filtering>false</filtering>
        <directory>${basedir}/src/main/plexus</directory>
        <includes>
          <include>configuration.xml</include>
        </includes>
        <excludes>
          <exclude>**/*.properties</exclude>
        </excludes>
      </resource>
    </resources>
    <testResources>
      ...
    </testResources>
    ...
  </build>
</project>

resources: is a list of resource elements that each describe what and where to include files associated with this project.
targetPath: Specifies the directory structure to place the set of resources from a build. Target path defaults to the base directory. A commonly specified target path for resources that will be packaged in a JAR is META-INF.
filtering: is true or false, denoting if filtering is to be enabled for this resource. Note, that filter *.properties files do not have to be defined for filtering to occur – resources can also use properties that are by default defined in the POM (such as ${project.version}), passed into the command line using the “-D” flag (for example, “-Dname=value“) or are explicitly defined by the properties element. Filter files were covered above.
directory: This element’s value defines where the resources are to be found. The default directory for a build is ${basedir}/src/main/resources.
includes: A set of files patterns which specify the files to include as resources under that specified directory, using * as a wildcard.
excludes: The same structure as includes, but specifies which files to ignore. In conflicts between include and exclude, exclude wins.
testResources: The testResources element block contains testResource elements. Their definitions are similar to resource elements, but are naturally used during test phases. The one difference is that the default (Super POM defined) test resource directory for a project is ${basedir}/src/test/resources. Test resources are not deployed.

git tag常用操作

2020年5月1日真三打老虎评论

前言

最近使用git来管理一个项目，到达一定阶段后，需要将稳定的代码发布成一个版本，经过查找资料发现git的标签操作刚好满足我的要求，所以记录下来，方便以后是使用查找。

用途

标签可以针对某一时间点的版本做标记，常用于版本发布，这恰恰是我所需要的功能，将本地标签推送到Github上即发布了一个Release版本，下载和查看非常方便。

标签分类

git标签分为两种类型：轻量标签和附注标签。轻量标签是指向提交对象的引用，附注标签则是仓库中的一个独立对象，建议使用附注标签，日后还可以查看标签信息。

创建标签

创建轻量标签

$ git tag v0.2.0 -light

解释：创建轻量标签不需要传递参数，直接指定标签名称即可。
创建附注标签

$ git tag -a v0.1.0 -m "release 0.1.0 version"

解释：创建附注标签时，参数-a即annotated的缩写，指定标签类型，后附标签名。参数m指定标签说明，说明信息会保存在标签对象中。

查看标签

列出当前仓库的所有标签

$ git tag
列出符合模式的标签

$ git tag -l 'v0.1.*'
查看标签版本信息

$ git show v0.1.0

切换标签

切换标签与切换分支命令相同

$ git checkout [tagname]

解释：切换标签后处于一个空的分支上，即”You are in ‘detached HEAD’ state.”

删除标签

误打或需要修改标签时，需要先将标签删除，再打新标签

$ git tag -d v0.1.2

解释：参数-d即delete的缩写，意为删除其后指定的标签。

补打标签

给指定的commit打标签

$ git tag -a v0.1.0 49e0cd22f6bd9510fe65084e023d9c4316b446a6

解释：打标签不必要在HEAD之上，也可在之前的版本上打，这需要你知道某个提交对象的校验和，通过git log命令获取。

发布标签

将v0.1.0标签提交到git服务器

$ git push origin v0.1.0

解释：通常的git push不会将标签对象提交到git服务器，我们需要进行显式的操作。
将本地所有标签一次性提交到git服务器

$ git push origin --tags

Git-herry-pick

2020年4月24日真三打老虎评论

cherry-pick 能干啥？

cherry，中文翻译是樱桃，pick，中文翻译是采集，挑选。所以，cherry-pick 就是挑选樱桃,git cherry-pick 就是从你的项目文件中找出”樱桃”二字，找到就可以找博主来兑换樱桃了。

以上是开玩笑，写博客呢，干什么，正经点！

cherry-pick 的翻译是择优挑选，使用git cherry-pick命令，可以选择将现有的一个或者多个提交的修改引入当前内容。

那么，什么情况下会有到这么不常见的命令呢？

假设你现在正在开发一个项目，有一个功能分支 feature，开发分支 develop。 feature 有3个提交，分别是 A ，B ，C 。develop 分支只想加入 C 功能，此时合并操作无法满足，因为直接合并 feature，会将3个提交都合并上，我想合并就只有 C，不要 A，B。此时就需要挑樱桃大法–cherry pick！

具体的做法：

切换到 develop 分支。
通过 git log feature,找到 C 的 SHA1 值。
通过 git cherry-pick <C的SHA1> ，将 C 的修改内容合并到当前内容分支 develop 中。
若无冲突，过程就已经完成了。如果有冲突，按正常冲突解决流程即可。

cherry-pick 示意图

cherry-pick VS merge, Ready? GO!

从上面简单的小例子上看，我想，小伙伴们，都应该已经对 merge 和 cherry-pick 有了大概的区分，这里做下对比，让大家有个清晰明确的掌握，防止似是而非，以后误操作。

git merge ：将两个提交历史合并。
git cherry-pick：将提交对应的内容合并。

这里，非常需要明确的一点，commit 代表的是修改！

例中，提交 C 的内容，就是对比 B 上面做的修改，可能是创建了一个文件，或者修改了一个词语。那么 C 内容就是一个文件的添加，和一个词语的修改。

以提交 C 为结束点的提交历史，实际内容是提交 C 和 C 之前所有的修改。

cherry-pick 操作的对象就是 commit。
merge 操作的对象就是 commit history。

所以，使用的时候，你要知道，你想要的什么。

博主邀请你参加挑樱桃游戏

光说不练假把式，现在写个小 demo 测试一下。

创建一个空文件夹 GitDemo,git init初始化。
随便创建一个文件，完成初次提交，创建 master 分支。
创建并切换 develop 分支，创建个提交，每一个提交中创建一个文件，方便测试。

具体命令如下：

// 切换到GitDemo目录下,并初始化Git
cd .../GitDemo  
git init  

//创建初次提交，创建 master 分支
touch cherry-pick.txt
git add .
git commit -m '创建cherry-pick文件，初次提交'  


//创建并切换到 develop 分支，创建提交“樱桃1号”
git checkout -b develop
touch 樱桃1号.txt
git add .
git commit -m "创建樱桃1号文件"


//创建提交“樱桃2号”
touch 樱桃2号.txt
git add .
git commit -m "创建樱桃2号文件"

//创建提交“樱桃3号”
touch 樱桃3号.txt
git add .
git commit -m "创建樱桃3号文件"

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

以上，测试场景构建完毕。现在用 git log develop 查看 develop 的提交历史如下：

现在，仔细瞅瞅，你最喜欢几号樱桃，喜欢哪个，就挑哪个。我喜欢3号，从上图看到3号的 SHA1 值是90279a36a8972034e922b65598adfc0c3e13679b,使用前几位就足够了。

//切换到 master 分支
git checkout master
//挑选3号樱桃
git cherry-pick 90279a36

1
2
3
4
5

挑选成功，通过 ls 命令，看到成功加入樱桃3号.txt。

挑樱桃游戏成功！

另外，需要说明的是，cherry-pick 到 master 的樱桃3号，事实上不是真的 3 号，是 3 号的复制品，两者的 SHA1 值是不同的，由此可确认这是两个提交。

了解更多的 cherry-pick

理解 cherry-pick 操作的本质，之后，再看其他的命令，就毫无压力了。全部命令详看官方文档，这里我给出几个比较常用的：

git cherry-pick <commits>

1
2

挑选多个提交合并,提交之间用空格相隔。例如，想挑选1号和3号的，就可以用git cherry-pick 4d2951 e4cdff9命令一步到位了。

git cherry-pick <start-commit>..<end-commit>

1
2

挑选一个范围的多个提交合并,但是这个语法对应操作区别是左开右闭，不包含start-commit。另外要注意两个commit 之间要求有连续关系的，并且前者要在后者之前，顺序不能颠倒。

git cherry-pick <start-commit>^..<end-commit>

1
2

这个和上面一样，区别就是加了一个^符号，就变成闭区间了，包含 start-commit。

git cherry-pick <branch name>
1

挑选 branch 最顶端的提交。例如挑选 3 号樱桃可以用git cherry-pick develop。

git cherry-pick --continue  //继续下个操作
git cherry-pick --quit //退出
git cherry-pick --abort //停止本次操作

1
2
3
4

以上是关于 cherry-pick 操作控制命令，当 cherry-pick 多个提交时，假设遇到冲突，--continue继续进行下个，--quit结束 cherry-pick 操作，但是不会影响冲突之前多个提交中已经成功的,--abort直接打回原形，回到 cherry-pick 前的状态，包括多个提交中已经成功的。

HTTP 协议中的 Transfer-Encoding

2020年4月19日真三打老虎评论

文章目录

Persistent Connection
Content-Length
Transfer-Encoding: chunked

提醒：本文最后更新于 942 天前，文中所描述的信息可能已发生改变，请谨慎使用。

本文作为我的博客「HTTP 相关」专题新的一篇，主要讨论 HTTP 协议中的 Transfer-Encoding。这个专题我会根据自己的理解，以尽量通俗的讲述，结合代码示例和实际场景来说明问题，欢迎大家关注和留言交流。

Transfer-Encoding，是一个 HTTP 头部字段，字面意思是「传输编码」。实际上，HTTP 协议中还有另外一个头部与编码有关：Content-Encoding（内容编码）。Content-Encoding 通常用于对实体内容进行压缩编码，目的是优化传输，例如用 gzip 压缩文本文件，能大幅减小体积。内容编码通常是选择性的，例如 jpg / png 这类文件一般不开启，因为图片格式已经是高度压缩过的，再压一遍没什么效果不说还浪费 CPU。

而 Transfer-Encoding 则是用来改变报文格式，它不但不会减少实体内容传输大小，甚至还会使传输变大，那它的作用是什么呢？本文接下来主要就是讲这个。我们先记住一点，Content-Encoding 和 Transfer-Encoding 二者是相辅相成的，对于一个 HTTP 报文，很可能同时进行了内容编码和传输编码。

Persistent Connection

暂时把 Transfer-Encoding 放一边，我们来看 HTTP 协议中另外一个重要概念：Persistent Connection（持久连接，通俗说法长连接）。我们知道 HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性，为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。为此，HTTP 协议引入了相应的机制。

HTTP/1.0 的持久连接机制是后来才引入的，通过 Connection: keep-alive 这个头部来实现，服务端和客户端都可以使用它告诉对方在发送完数据之后不需要断开 TCP 连接，以备后用。HTTP/1.1 则规定所有连接都必须是持久的，除非显式地在头部加上 Connection: close。所以实际上，HTTP/1.1 中 Connection 这个头部字段已经没有 keep-alive 这个取值了，但由于历史原因，很多 Web Server 和浏览器，还是保留着给 HTTP/1.1 长连接发送 Connection: keep-alive 的习惯。

浏览器重用已经打开的空闲持久连接，可以避开缓慢的三次握手，还可以避免遇上 TCP 慢启动的拥塞适应阶段，听起来十分美妙。为了深入研究持久连接的特性，我决定用 Node 写一个最简单的 Web Server 用于测试，Node 提供了 http 模块用于快速创建 HTTP Web Server，但我需要更多的控制，所以用 net 模块创建了一个 TCP Server：

JSrequire('net').createServer(function(sock) {
    sock.on('data', function(data) {
        sock.write('HTTP/1.1 200 OK\r\n');
        sock.write('\r\n');
        sock.write('hello world!');
        sock.destroy();
    });
}).listen(9090, '127.0.0.1');

启动服务后，在浏览器里访问 127.0.0.1:9090，正确输出了指定内容，一切正常。去掉 sock.destroy() 这一行，让它变成持久连接，重启服务后再访问一下。这次的结果就有点奇怪了：迟迟看不到输出，通过 Network 查看请求状态，一直是 pending。

这是因为，对于非持久连接，浏览器可以通过连接是否关闭来界定请求或响应实体的边界；而对于持久连接，这种方法显然不奏效。上例中，尽管我已经发送完所有数据，但浏览器并不知道这一点，它无法得知这个打开的连接上是否还会有新数据进来，只能傻傻地等了。

Content-Length

要解决上面这个问题，最容易想到的办法就是计算实体长度，并通过头部告诉对方。这就要用到 Content-Length 了，改造一下上面的例子：

JSrequire('net').createServer(function(sock) {
    sock.on('data', function(data) {
        sock.write('HTTP/1.1 200 OK\r\n');
        sock.write('Content-Length: 12\r\n');
        sock.write('\r\n');
        sock.write('hello world!');
    });
}).listen(9090, '127.0.0.1');

可以看到，这次发送完数据并没有关闭 TCP 连接，但浏览器能正常输出内容并结束请求，因为浏览器可以通过 Content-Length 的长度信息，判断出响应实体已结束。那如果 Content-Length 和实体实际长度不一致会怎样？有兴趣的同学可以自己试试，通常如果 Content-Length 比实际长度短，会造成内容被截断；如果比实体内容长，会造成 pending。

由于 Content-Length 字段必须真实反映实体长度，但实际应用中，有些时候实体长度并没那么好获得，例如实体来自于网络文件，或者由动态语言生成。这时候要想准确获取长度，只能开一个足够大的 buffer，等内容全部生成好再计算。但这样做一方面需要更大的内存开销，另一方面也会让客户端等更久。

我们在做 WEB 性能优化时，有一个重要的指标叫 TTFB（Time To First Byte），它代表的是从客户端发出请求到收到响应的第一个字节所花费的时间。大部分浏览器自带的 Network 面板都可以看到这个指标，越短的 TTFB 意味着用户可以越早看到页面内容，体验越好。可想而知，服务端为了计算响应实体长度而缓存所有内容，跟更短的 TTFB 理念背道而驰。但在 HTTP 报文中，实体一定要在头部之后，顺序不能颠倒，为此我们需要一个新的机制：不依赖头部的长度信息，也能知道实体的边界。

Transfer-Encoding: chunked

本文主角终于再次出现了，Transfer-Encoding 正是用来解决上面这个问题的。历史上 Transfer-Encoding 可以有多种取值，为此还引入了一个名为 TE 的头部用来协商采用何种传输编码。但是最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。

分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF（\r\n），也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。按照这个格式改造下之前的代码：

JSrequire('net').createServer(function(sock) {
    sock.on('data', function(data) {
        sock.write('HTTP/1.1 200 OK\r\n');
        sock.write('Transfer-Encoding: chunked\r\n');
        sock.write('\r\n');

        sock.write('b\r\n');
        sock.write('01234567890\r\n');

        sock.write('5\r\n');
        sock.write('12345\r\n');

        sock.write('0\r\n');
        sock.write('\r\n');
    });
}).listen(9090, '127.0.0.1');

上面这个例子中，我在响应头中表明接下来的实体会采用分块编码，然后输出了 11 字节的分块，接着又输出了 5 字节的分块，最后用一个 0 长度的分块表明数据已经传完了。用浏览器访问这个服务，可以得到正确结果。可以看到，通过这种简单的分块策略，很好的解决了前面提出的问题。

前面说过 Content-Encoding 和 Transfer-Encoding 二者经常会结合来用，其实就是针对进行了内容编码（压缩）的内容再进行传输编码（分块）。下面是我用 telnet 请求测试页面得到的响应，可以看到对 gzip 内容进行的分块：

BASH> telnet 106.187.88.156 80

GET /test.php HTTP/1.1
Host: qgy18.qgy18.com
Accept-Encoding: gzip

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 03 May 2015 17:25:23 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip

1f
�H���W(�/�I�J

0

Android Studio3.6编辑器中文乱码

2020年3月21日2020年3月21日真三打老虎评论

最近下载了最新的Android Studio3.6,发现不管java文件编辑还是xml文件编辑，里边的中文都会显示乱码，但是用NotePad++打开时正常的。在网上找了好久，来回改utf-8,gbk,gb2312,都不正确，根本原因是因为Editor缺失了fallback 字体，导致中文字体在默认的字体下显示错乱。

在Android Studio3.6中如下：

同样的xml文件用NotePad++ 打开就是正常的，如下：

网上很多说法是改Idiea的文件编码，如下图所示：

其实这个只是更改文件默认的编码方式，并不能解决根本问题。

尝试了很多，终于发现原因是没有fallback字体：
共需要修改两处：
1、设置->Editor->Font 修改 Fallback font 为 simsun 宋体
2、设置->Editor->Color Scheme->Color Scheme Font 修改 Fallback font 为 simsun 宋体

操作如下：