这是jar冲突，版本太高引起的，maven3.5.0版本有这个问题，使用3.3.9低版本就可以了
用于tomcat7自动部署的管理用户必须具有manager-script角色,manager-gui角色是不够的，不然会有错误出现：The username you provided is not allowed to use the text-based Tomcat Manager (error 403)
在/etc/tomcat7/tomcat-users.xml文件中为管理用户添加manager-script角色即可。
进入\Jenkins\secrets目录，打开initialAdminPassword文件，复制密码；
访问Jenkins页面，输入管理员admin，及刚才的密码；
进入后可更改其他管理员密码；
1 | <useSecurity>true</useSecurity> |
重启Jenkins服务；
进入首页>“系统管理”>“Configure Global Security”；
勾选“启用安全”；
点选“Jenkins专有用户数据库”，并点击“保存”；
重新点击首页>“系统管理”,发现此时出现“管理用户”；
点击进入展示“用户列表”；
点击右侧进入修改密码页面，修改后即可重新登录。
nexus的repository分三种类型：Hosted、 Proxy和Virtual，另外还有一个repository group(仓库组)用于对多个仓库进行组合。部署的时候只能部署到Hosted类型的仓库中，如果是其他类型就会出现这个400错误。
默认情况下部署构件到Releases仓库中有时也会出现400错误，这个原因就像上面提到的那样，Nexus中 Releases仓库默认的Deployment Policy是“Disable Redeploy”，所以无论你在settings.xml文件中将server的username设置为deployment还是使用admin都是无 法部署的，就会出现这个400错误。
Nexus中 Releases仓库Respository PolicySnapshot是“Release”。Snapshot仓库Respository PolicySnapshot是“Snapshot” 如果设置反了或错了也是无法部署的。
如果你Snapshot可以发布，但是releases却发布不了，可能是
在settings.xml的<servers></servers>中配置账号密码
1 | <server> |
nexus的仓库类型分为以下四种：
首次登陆nexus后可以看到以下一个仓库组和多个仓库。
新搭建的neuxs环境只是一个空的仓库，需要手动和远程中心库进行同步，nexus默认是关闭远程索引下载，最重要的一件事情就是开启远程索引下载。登陆nexus系统，默认用户名密码为admin/admin123。
点击左边Administration菜单下面的Repositories，找到右边仓库列表中的三个仓库Apache Snapshots，Codehaus Snapshots和Maven Central，然后再没有仓库的configuration下把Download Remote Indexes修改为true。
然后在Apache Snapshots，Codehaus Snapshots和Maven Central这三个仓库上分别右键，选择Repari Index，这样Nexus就会去下载远程的索引文件。
步骤为Repositories –> Add –> Hosted Repository
Nexus 中仓库组的概念是Maven没有的，在Maven看来，不管你是hosted也好，proxy也好，或者group也好，对我都是一样的，我只管根据 groupId，artifactId，version等信息向你要构件。为了方便Maven的配置，Nexus能够将多个仓库，hosted或者 proxy合并成一个group，这样，Maven只需要依赖于一个group，便能使用所有该group包含的仓库的内容。
转自：http://www.cnblogs.com/zhoujg/archive/2015/12/17/5053789.html
schema.xml位于solr/conf/目录下，类似于数据表配置文件，定义了加入索引的数据的数据类型，主要包括type、fields和其他的一些缺省设置。Solr的schema配置是非常灵活和丰富，下面将对此进行详细介绍。
先来看一个简单的schema配置：
1 | <?xml version="1.0" encoding="UTF-8" ?> |
schema.xml 配置文件的根元素就是 schema, 有个 name 属性， name 属性值可以随便配，根元素没什么好说的， schema 元素下主要有两个标签元素即 field 和fieldType,field 表示域，用来定义域， fieldType 用来定义域类型。
在fields结点内定义具体的字段（类似数据库中的字段），就是filed，filed定义包括name,type（为之前定义过的各种FieldType）,indexed（是否被索引）,stored（是否被储存），multiValued（是否有多个值）等等。
例：
1 | <fields> |
Field即结构化中得某一个字段，field属性说明：
field的定义相当重要，有几个技巧需注意一下：
field 里还有两个比较难理解的域，是 Solr 扩展的，在 Lucene 中没有的概念，即dynamicField 动态域和 copyField 复制域：
正常数据结构一个是需要考虑中文分词，二个是考虑是否索引，是否分词，是否存储等等。下面的示范用到了三种类型的数据：
不存在不需要索引、也不需要分词，也不需要存储的字段，因为这样的字段在Lucene中无意义。
示范配置：
1 | <?xml version="1.0" ?> |
动态域的属性配置跟普通的 field 差不多就不多说了，唯一有点区别就是 name 的属性值，可以用通配符，这样就可以模糊匹配多个域啦，这样设计的目的就是不用频繁的去修改我们的 schema.xml 中的 field 配置去增加 field 域啦，比如之前有个 link_s域，某一天你想再增加一个 url_s 域，那你就需要去修改 schema.xml 配置文件，由于schema.xml 修改过后需要重启 tomcat 才能生效，重启即意味着程序的中断，这往往是不可接受的。所以引入动态域来避免频繁添加修改域，但前提是你的域需要符合你提前定义的动态域的域名称命名规则哦。
1 | <dynamicField name="*_i" type="int" indexed="true" stored="true"/> |
建议建立一个拷贝字段，将所有的 全文本 字段复制到一个字段中，以便进行统一的检索。
假如有一个文章schema，一开始业务系统搜索的时候主要是搜索文章的内容，后来我希望搜索的时候能同时去搜索文章的标题，使用copyField，将标题和内容冗余为一个字段。
例如：
1 | <field name="title" type="text_general" indexed="true" stored="true"/> |
拷贝字段就是查询的时候不用再输入：title:张三 and content:张三的个人简介。直接可以输入”张三”就可以将“名字”含“张三”或者“简介”中含“张三”的查询出来。他将需要查询的内容放在了一个字段中，并且默认查询该字段设为该字段就行了。
要注意的是，如果你只是复制单个域，那么如果你被复制域本身就是多值域，那么目标域也是多值域，这毋庸置疑，那如果你复制的是多个域，只要其中有一个域是多值域，那么目标域就一定是多值域，这点一定要谨记。
field 说完了，接着说说 fieldType 元素，它用来定义域类型， solr 内置的域类型有StrField ， BoolField ， TrieIntField ， TrieFloatField ， TrieLongField ，TrieDoubleField ， TrieDateField ， BinaryField ， RandomSortField ， TextField等，其他更多域类型请自己查阅 Solr API 文档。
1 | <fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/> |
field type是对field类型的详细描述：
fieldType 元素还有一些额外的属性也需要注意下，比如sortMissingFirst,sortMissingLast 等：
在FieldType定义的时候最重要的就是定义这个类型的数据在建立索引和进行查询的时候要使用的分析器analyzer,包括分词和过滤。必要的时候fieldType还需要自己定义这个类型的数据在建立索引和进行查询的时候要使用的分析器analyzer，包括分词和过滤。
例如：
1 | <fieldType name="text" class="solr.TextField" positionIncrementGap="100"> |
在index的analyzer中使用 solr.WhitespaceTokenizerFactory这个分词包，就是空格分词，然后使用 solr.StopFilterFactory，solr.WordDelimiterFilterFactory，solr.LowerCaseFilterFactory，solr.EnglishPorterFilterFactory，solr.RemoveDuplicatesTokenFilterFactory 这几个过滤器。在向索引库中添加text类型的索引的时候，Solr会首先用空格进行分词，然后把分词结果依次使用指定的过滤器进行过滤，最后剩下的结果才会加入到索引库中以备查询。Solr的analysis包并没有带支持中文分词的包。
最后需要说的就是 uniqueKey 元素，它用来配置 document 的唯一标识域，即 solr是用此域来决定增量导入时是否重复导入，如果 id 一样，则不会重复导入，或者当你更新索引时，你可以根据指定的 uniqueKey 域，来确定一个 document ，然后对该document 进行更新。总之，它是用来唯一确定一个 document 的，跟数据库表里的主键 id 概念类似，前提是你 uniqueKey 里配置的域名称你需要提前使用 field 元素进行定义。
schema.xml里有一个uniqueKey,的配置，这里将id字段作为索引文档的唯一标识符，非常重要。
1 | <uniqueKey>id</uniqueKey> |
转自：http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
格式化的Commit message，有几个好处。
比如，下面的命令显示上次发布后的变动，每个commit占据一行。你只看行首，就知道某次 commit 的目的。
1 | $ git log <last tag> HEAD --pretty=format:%s |
比如，下面的命令仅仅显示本次发布新增加的功能。
1 | $ git log <last release> HEAD --grep feature |
Change Log 是发布新版本时，用来说明与上一个版本差异的文档，详见后文。
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
1 | <type>(<scope>): <subject> |
其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type用于说明 commit 的类别，只允许使用下面7个标识。
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject是 commit 目的的简短描述，不超过50个字符。
Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
1 | More detailed explanatory text, if necessary. Wrap it to |
有两个注意点。
Footer 部分只用于两种情况。
1 | BREAKING CHANGE: isolate scope bindings definition has changed. |
1 | Closes #234 |
1 | Closes #123, #245, #992 |
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。
1 | revert: feat(pencil): add 'graphiteWidth' option |
Body部分的格式是固定的，必须写成This reverts commit <hash>.，其中的hash是被撤销 commit 的 SHA 标识符。
如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。
Commitizen是一个撰写合格 Commit message 的工具。
安装命令如下。
1 | $ npm install -g commitizen |
然后，在项目目录里，运行下面的命令，使其支持 Angular 的 Commit message 格式。
1 | $ commitizen init cz-conventional-changelog --save --save-exact |
以后，凡是用到git commit命令，一律改为使用git cz。这时，就会出现选项，用来生成符合格式的 Commit message。
validate-commit-msg 用于检查 Node 项目的 Commit message 是否符合格式。
它的安装是手动的。首先，拷贝下面这个JS文件，放入你的代码库。文件名可以取为validate-commit-msg.js。
接着，把这个脚本加入 Git 的 hook。下面是在package.json里面使用 ghooks，把这个脚本加为commit-msg时运行。
1 | "config": { |
然后，每次git commit的时候，这个脚本就会自动检查 Commit message 是否合格。如果不合格，就会报错。
1 | $ git add -A |
如果你的所有 Commit 都符合 Angular 格式，那么发布新版本时， Change log 就可以用脚本自动生成（例1，例2，例3）。
生成的文档包括以下三个部分。
每个部分都会罗列相关的 commit ，并且有指向这些 commit 的链接。当然，生成的文档允许手动修改，所以发布前，你还可以添加其他内容。
conventional-changelog 就是生成 Change log 的工具，运行下面的命令即可。
1 | $ npm install -g conventional-changelog |
上面命令不会覆盖以前的 Change log，只会在CHANGELOG.md的头部加上自从上次发布以来的变动。
如果你想生成所有发布的 Change log，要改为运行下面的命令。
1 | $ conventional-changelog -p angular -i CHANGELOG.md -w -r 0 |
为了方便使用，可以将其写入package.json的scripts字段。
1 | { |
以后，直接运行下面的命令即可。
1 | $ npm run changelog |
正常是 type 有值才会使用这个条件
1 | <if test="type != null and type != ''"> |
1 | int i = 0; |
正常来说，0不为空也不是空字符串。所以，针对这个问题，我的解决办法是：如果类型为Integer类型，我就去掉 ！= ”的判断，只判断!=null即可。
非严格的thymeleaf格式
你可能会发现在默认配置下，thymeleaf对.html的内容要求很严格，比如，如果少最后的标签封闭符号/，就会报错而转到错误页。也比如你在使用Vue.js这样的库，然后有
这样的html代码，也会被thymeleaf认为不符合要求而抛出错误。因此，建议增加下面这段：
spring.thymeleaf.mode = LEGACYHTML5。spring.thymeleaf.mode的默认值是HTML5，其实是一个很严格的检查，改为LEGACYHTML5可以得到一个可能更友好亲切的格式要求。
需要注意的是，LEGACYHTML5需要搭配一个额外的库NekoHTML才可用。
转自：https://davidzych.com/difference-between-git-reset-soft-mixed-and-hard/
The reset command. Confusing. Misunderstood. Misused. But it doesn’t need to be that way! It’s really not too confusing once you figure out what’s going on.
First, let’s define a few terms.
This is an alias for the tip of the current branch, which is the most recent commit you have made to that branch.
The index, also known as the staging area, is the set of files that will become the next commit. It is also the commit that will become HEAD’s parent.
This is the term for the current set of files you’re working on in your file system.
When you first checkout a branch, HEAD points to the most recent commit in the branch. The files in the HEAD (they aren’t technically files, they’re blobs but for the purposes of this discussion we can think of them as straight files) match that of the files in the index, and the files checked out in your working copy match HEAD and the index as well. All 3 are in an equal state, and Git is happy.
When you perform a modification to a file, Git notices and says “oh, hey, something has changed. Your working copy no longer matches the index and HEAD.” So it marks the file as changed.
Then, when you do a git add, it stages the file in the index, and Git says “oh, okay, now your working copy and index match, but those are both different than HEAD.”
When you then perform a git commit, Git creates a new commit that HEAD now points to and the status of the index and working copy match it so Git’s happy once more.
If you just look at the reset command by itself, all it does is reset HEAD (the tip of the current branch) to another commit. For instance, say we have a branch (the name doesn’t matter, so let’s call this one “super-duper-feature”) and it looks like so:
If we perform:
1 | > git reset HEAD |
… nothing happens. This is because we tell git to reset this branch to HEAD, which is where it already is. But if we do:
1 | > git reset HEAD~1 |
(HEAD~1 is shorthand case for “the commit right before HEAD”, or put differently “HEAD’s parent”) our branch now looks like so:
If we start at the latest commit again and do:
1 | > git reset HEAD~2 |
our branch would look like so:
Again, all it does on a basic level is move HEAD to another commit.
So the reset command itself is pretty simple, but it’s the parameters that cause confusion. The main parameters are soft, hard and mixed. These tell Git what to do with your index and working copy when performing the reset.
The –soft parameter tells Git to reset HEAD to another commit, but that’s it. If you specify –soft Git will stop there and nothing else will change. What this means is that the index and working copy don’t get touched, so all of the files that changed between the original HEAD and the commit you reset to appear to be staged.
The –mixed parameter (which is the default if you don’t specify anything) will reset HEAD to another commit, and will reset the index to match it, but will stop there. The working copy will not be touched. So, all of the changes between the original HEAD and the commit you reset to are still in the working copy and appear as modified, but not staged.
The –hard parameter will blow out everything – it resets HEAD back to another commit, resets the index to match it, and resets the working copy to match it as well. This is the more dangerous of the commands and is where you can cause damage. Data might get lost here*!
