maven resource解释

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:

  1. <project xmlns="http://maven.apache.org/POM/4.0.0"
  2. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3. xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
  4. https://maven.apache.org/xsd/maven-4.0.0.xsd">
  5. <build>
  6. ...
  7. <resources>
  8. <resource>
  9. <targetPath>META-INF/plexus</targetPath>
  10. <filtering>false</filtering>
  11. <directory>${basedir}/src/main/plexus</directory>
  12. <includes>
  13. <include>configuration.xml</include>
  14. </includes>
  15. <excludes>
  16. <exclude>**/*.properties</exclude>
  17. </excludes>
  18. </resource>
  19. </resources>
  20. <testResources>
  21. ...
  22. </testResources>
  23. ...
  24. </build>
  25. </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常用操作


前言

最近使用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

Android Studio3.6编辑器中文乱码

最近下载了最新的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 宋体

操作如下:

Mybatis中自动注册的TypeHandler

register(Boolean.class, new BooleanTypeHandler());
register(boolean.class, new BooleanTypeHandler());
register(JdbcType.BOOLEAN, new BooleanTypeHandler());
register(JdbcType.BIT, new BooleanTypeHandler());
register(Byte.class, new ByteTypeHandler());
register(byte.class, new ByteTypeHandler());
register(JdbcType.TINYINT, new ByteTypeHandler());
register(Short.class, new ShortTypeHandler());
register(short.class, new ShortTypeHandler());
register(JdbcType.SMALLINT, new ShortTypeHandler());
register(Integer.class, new IntegerTypeHandler());
register(int.class, new IntegerTypeHandler());
register(JdbcType.INTEGER, new IntegerTypeHandler());
register(Long.class, new LongTypeHandler());
register(long.class, new LongTypeHandler());
register(Float.class, new FloatTypeHandler());
register(float.class, new FloatTypeHandler());
register(JdbcType.FLOAT, new FloatTypeHandler());
register(Double.class, new DoubleTypeHandler());
register(double.class, new DoubleTypeHandler());
register(JdbcType.DOUBLE, new DoubleTypeHandler());
register(Reader.class, new ClobReaderTypeHandler());
register(String.class, new StringTypeHandler());
register(String.class, JdbcType.CHAR, new StringTypeHandler());
register(String.class, JdbcType.CLOB, new ClobTypeHandler());
register(String.class, JdbcType.VARCHAR, new StringTypeHandler());
register(String.class, JdbcType.LONGVARCHAR, new ClobTypeHandler());
register(String.class, JdbcType.NVARCHAR, new NStringTypeHandler());
register(String.class, JdbcType.NCHAR, new NStringTypeHandler());
register(String.class, JdbcType.NCLOB, new NClobTypeHandler());
register(JdbcType.CHAR, new StringTypeHandler());
register(JdbcType.VARCHAR, new StringTypeHandler());
register(JdbcType.CLOB, new ClobTypeHandler());
register(JdbcType.LONGVARCHAR, new ClobTypeHandler());
register(JdbcType.NVARCHAR, new NStringTypeHandler());
register(JdbcType.NCHAR, new NStringTypeHandler());
register(JdbcType.NCLOB, new NClobTypeHandler());
register(Object.class, JdbcType.ARRAY, new ArrayTypeHandler());
register(JdbcType.ARRAY, new ArrayTypeHandler());
register(BigInteger.class, new BigIntegerTypeHandler());
register(JdbcType.BIGINT, new LongTypeHandler());
register(BigDecimal.class, new BigDecimalTypeHandler());
register(JdbcType.REAL, new BigDecimalTypeHandler());
register(JdbcType.DECIMAL, new BigDecimalTypeHandler());
register(JdbcType.NUMERIC, new BigDecimalTypeHandler());
register(InputStream.class, new BlobInputStreamTypeHandler());
register(Byte[].class, new ByteObjectArrayTypeHandler());
register(Byte[].class, JdbcType.BLOB, new BlobByteObjectArrayTypeHandler());
register(Byte[].class, JdbcType.LONGVARBINARY, new BlobByteObjectArrayTypeHandler());
register(byte[].class, new ByteArrayTypeHandler());
register(byte[].class, JdbcType.BLOB, new BlobTypeHandler());
register(byte[].class, JdbcType.LONGVARBINARY, new BlobTypeHandler());
register(JdbcType.LONGVARBINARY, new BlobTypeHandler());
register(JdbcType.BLOB, new BlobTypeHandler());
register(Object.class, UNKNOWN_TYPE_HANDLER);
register(Object.class, JdbcType.OTHER, UNKNOWN_TYPE_HANDLER);
register(JdbcType.OTHER, UNKNOWN_TYPE_HANDLER);
register(Date.class, new DateTypeHandler());
register(Date.class, JdbcType.DATE, new DateOnlyTypeHandler());
register(Date.class, JdbcType.TIME, new TimeOnlyTypeHandler());
register(JdbcType.TIMESTAMP, new DateTypeHandler());
register(JdbcType.DATE, new DateOnlyTypeHandler());
register(JdbcType.TIME, new TimeOnlyTypeHandler());
register(java.sql.Date.class, new SqlDateTypeHandler());
register(java.sql.Time.class, new SqlTimeTypeHandler());
register(java.sql.Timestamp.class, new SqlTimestampTypeHandler());

package.json和package-lock.json的区别

介绍


把npm更新到v5.x.x以后, 会出现一种新的自动生成文件 – Package-lock.json. 如果打开这个文件, 会发现它看着像package.json里面的依赖.

背景知识


  • 在解package.jsonpackage-lock.json前, 需要先了解semver 语义化版本号变更. 它是npm依赖管理背后的精髓. 点这里了解npm是如何使用它的. 总的来说, 所谓的语义化版本号变更, 就是当你修改了你所维护的第三方库时, 告诉那些使用了你的库的项目, 你做的是哪种修改. 一个版本号分为三个部分: X,Y,Z. X表示主版本号, Y表示次版本号, Z表示补丁更新. 当你只是简单的修复了BUG, 没有做任何新功能的添加, 或者旧功能的修改, 就需要更新补丁号(数值加一等等). 当你添加了新的功能, 但没有破坏原有的功能, 就需要更新次版本号. 当你做了重大修改导致新版本不兼容旧的代码时, 就需要更新主版本号.
  • ^ 是npm默认的版本符号, 当你使用npm install --save时, npm会自动在package中添加^加上版本号. 例如: npm install --save angular会在package.json中添加"angular": "^1.3.15".这个符号会告诉npm可以安装1.3.15或者一个大于它的版本, 但是要是主版本1下的版本.
  • ~同样被用来做npm得版本控制, 例如~1.3.15, 代表了npm可以安装1.3.15或者更高的版本, 与^的区别在于, ~的版本只能开始于次版本号1.3. 它们的作用域不同. 你可以通过npm config set save-prefix='~'~设置为默认符号.
  • >符号主要是用来指定可以安装beta版本.

包管理


当你添加了一个依赖时, package.json里面会加一项条目, 包含包的名称, 并且使用semver来处理版本号. npm支持版本号中包含通配符. 一般来说, npm会安装最新的版本的依赖, 并且在版本号前面加上^符号, 比如^1.2.12. 这表示, 至少要安装1.2.12的版本, 但更高的版本也可以, 只要主版本号也为1就行. 因为补丁号和次版本号的变动不会变更已有的API. 你应该可以安全地使用任何主版本一致的更高版本依赖. 你可以点击这里的版本计算器, 了解通配符的含义.

使用场景


把依赖记录在package.json里面的优点是, 只要别人可以访问package.json, 他就可以安装里面所记录的依赖, 然后就可以直接运行你的项目了. 不过有些时候, 这样子会出现一个问题.

比如我们的项目用了express这个框架. 我们使用npm init初始化项目后, 使用命令npm install express –save安装了依赖. express的版本号是4.15.4, 所以package.json里面express的版本号会是^4.15.4, 然后电脑上面就安装了版本为4.15.4的express. 然后可能第二天, express的维护者修复了一个BUG, 现在最新版本变成了4.15.5. 接着, 有个人觉得我们的项目很不错, 他想贡献一些代码, 于是它clone下来, 运行了npm install. 由于最新express版本是4.15.5, 并且主版本号也是一致的, 因此他的电脑上安装的版本就是4.15.5. 我们都安装了express, 但是版本却不一样.

理论上来说, 这两个版本应该是兼容的, 但是可能那个修复的BUG影响到了我们所使用的功能, 使得在这两个不同的版本上出现不同运行结果.

package-lock.json


package-lock.json诞生的目的是为了防止出现我们上述的情况. 同一个package.json却产生了不同的运行结果. package-lock.json在npm 5时添加进来, 所以如果你使用5以上的版本, 你就会看到这个文件, 除非你手动禁用掉它. 所以从此以后npm会根据package-lock.json里的内容来处理和安装依赖而不是根据package.json. 因为pacakge-lock.json给每个依赖标明了版本, 获取地址和哈希值, 使得每次安装都会出现相同的结果. 不管你在什么机器上面或什么时候安装。

  • 官方定义

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates. This file is intended to be committed into source repositories, and serves various purposes.
大概意思是, 当我们对node_modules或者package.json进行了更改后, package-lock.json文件会自动生成. 里面会描述上一次更改后的确切的依赖管理树. 里面包含了唯一的版本号和相关的包信息. 之后的npm install会根据package-lock.json文件进行安装, 保证不同环境, 不同时间下的依赖是一样的.
还有一个好处是, 由于package-lock.json文件中记录了下载源地址, 可以加快我们的npm install速度

  • 格式

package-lock.json是一个包含你所有依赖的巨大列表, 它包含明确的版本号(没有通配符), 依赖的获取地址, 一个用于验证完整性和正确性的哈希值, 以及这个依赖本身所需要的依赖.

"express": {
  "version": "4.15.4",
  "resolved": "https://registry.npmjs.org/express/-/express-4.15.4.tgz",
  "integrity": "sha1-Ay4iU0ic+PzgJma+yj0R7XotrtE=",
  "requires": {
    "accepts": "1.3.3",
    "array-flatten": "1.1.1",
    "content-disposition": "0.5.2",
    "content-type": "1.0.2",
    "cookie": "0.3.1",
    "cookie-signature": "1.0.6",
    "debug": "2.6.8",
    "depd": "1.1.1",
    "encodeurl": "1.0.1",
    "escape-html": "1.0.3",
    "etag": "1.8.0",
    "finalhandler": "1.0.4",
    "fresh": "0.5.0",
    "merge-descriptors": "1.0.1",
    "methods": "1.1.2",
    "on-finished": "2.3.0",
    "parseurl": "1.3.1",
    "path-to-regexp": "0.1.7",
    "proxy-addr": "1.1.5",
    "qs": "6.5.0",
    "range-parser": "1.2.0",
    "send": "0.15.4",
    "serve-static": "1.12.4",
    "setprototypeof": "1.0.3",
    "statuses": "1.3.1",
    "type-is": "1.6.15",
    "utils-merge": "1.0.0",
    "vary": "1.1.1"
  }
},

官方文档

package-lock.json