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

Git-herry-pick


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!

具体的做法:

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

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 测试一下。

  1. 创建一个空文件夹 GitDemo,git init初始化。
  2. 随便创建一个文件,完成初次提交,创建 master 分支。
  3. 创建并切换 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 前的状态,包括多个提交中已经成功的。