3.当我们已经新建好一个插件工程后，下一步我们就要思考了，我们要做的这个插件，到底是要做什么？别急，jira会指导你下一步要做什么，先进入 我们刚新建的插件工程里，也就是pom.xml所在的那级目录下（E:\Atlassian\myPlugin\MyPlugin），然后敲下atlas-create-jira-plugin-module指令，出现下图：
除了down jar包的信息之外，最后跳出了34种plugin module，并需要你继续输入，解释一下，jira支持的插件类型一共就屏幕上列出来的这34种，每一种都有它应该使用的场景，如一开始，我贴图中的，想做一个自定义类型字段的插件，那么应该是什么？看下第4种Custom Field（自定义字段），因为我这次poc的所用到的就两种（还有一种是workflow post function），其他的插件类型，我就不发表意见了，抛砖引玉，回归官网文档上，所有的插件类型，这个只有去官网文档上去找了（关键字就是plugin module,左边的导航栏里有个plugin module index ），上面有很详细的解释，以及属性设置，这里我选4，回车
Enter New Classname MyCustomField: ----------------------------------让你输入一个类名，默认叫做MyCustomField，我改成TestCustomField
Enter Package Name com.test.zt.jira.customfields: :------------------------输入包名，默认是com.test.zt.jira.customfields，保持默认吧
Show Advanced Setup? (Y/y/N/n) N: :----------------------------是否采用高级安装，这里我们选择N，之前选过一次Y，还有一大堆要设置的地方，采用默认吧，小伙伴你们选Y可以试一下，根据屏幕的提示，继续定制一下
Add Another Plugin Module? (Y/y/N/n) N: :---------------------------------是否需要在增加一个插件类型？看来，同一个maven工程里，我们可以增加很多插件类型，这里我们就简单一点选N ，不需要
然后，就开始build了，截图如下：
因为之前已经导入过eclipse里了，所以，不在windows浏览了，直接在eclipse里观察，看看目录结构有什么变化
红色部分是新增的文件，看下名字，就是我们上面在cmd中输入的信息，这边有个编译错误，当个小插曲吧
The type java.util.Optional cannot be resolved. It is indirectly referenced from required .class files
java.util.Optional是1.8才出的特性,项目中maven导入进来时候，却指定的版本是1.5，所以引用jdk有问题吧，因为maven工程创建是由SDK创建的，这里不过多纠结为什么是引用1.5了，直接eclipse改成1.8jdk,
先看下新增的那个类，TestCustomField.java，也是自动builder，然后继承了TextCFType，我们先什么都不用改，里面的方法，暂时也不用管什么意思 ，既然是做插件，目的就是快捷，方便二次开发，如果要去彻底研究透源码，代价太大了，况且也不现实，jira不开源，即使有开源的地方，也是方便于二次开发的部分。比如rest api，那个是有源码可以参考的。
ok,我们看下最重要的一个文件，atlassian-plugin.xml，多了以下部分：
customfield-type这种类型 就是自定义字段类型，里面很多属性 比如name,i18n-name-key 等等，这些应该设置什么值，这里不多数了，还是那句话，去官网查这种类型的插件相关文档，官方有整个一页的介绍，还是那句话，抛砖引玉，就和写java一样，随时备着jdk的javadoc，用的时候就去查
然后再看下，两个vm文件,因为本人volecity不熟悉，都是现查现用，这两个文件 一个叫edit，一个叫view，顾名思义，一个是编辑的时候，显示的样子，一个是查看的时候显示的样子，这么想没什么概念，但是你联想下ira页面操作的时候，创建问题和编辑问题，还有查看问题这三种行为的时候，然后就能明白一二了，而且，前台这种渲染模板文件采用的是volecity,也不支持什么jsp,html,ftl等，貌似只支持volecity
4.OK，至此，插件开发完毕（虽然在这里什么都没做，都是用的默认的代码，未来如果有定制化的话，流程上就需要去改变java类，显示的话就需要vm文件），下面，让我们将这个插件部署到jira中去，养兵千日，用兵一时，总要在jira上能用起来吧？
这边提到两个部署环境，当然，官方没有这些概念，这是我站在开发角度，定义个两个名称吧，第一个叫做正式环境 一个叫做开发环境，前者就是指我们正常使用的jira环境，正常上传插件，就可以使用， 后者是依赖SDK，自动构建出的一个web环境，版本号与SDK版本有关，这就是上面我提到，有个260M左右的web容器，此开发环境是免费的，默认连的它的h2 database,如果要换成其他什么库，比如sqlserver,那么启动后就会提示你需要licence了，由于SDK下的最新，里面的jira版本可能也比较新，破解可能还不大好被破解，所以，这里不麻烦了，采用它默认的h2数据库，
好吧，我们开发的话，可能更多要关注这个开发环境了，首先，要启动这个环境吧。同样，cmd先进入 我们上面建的插件的根目录，也就是pom.xml所在的目录（为什么老是说这个pom.xml，这个pom.xml可以打开看一下，也是别有一番洞天） 输入：atlas-run 或者 atlas-debug 回车 (这些指令从哪里来？还记得sdk安装后的bin目录么，进去看看吧)，然后就是漫长的等待，又开始down jar包 还有那个最恐怖的web容器的包，所有需要的东西都down完之后，就开始启动tomcat了，启动成功后，就可以访问jira了，地址是：http://localhost:2990/jira/ 这里提下，因为是开发，可能需要debug调试，那么就采用atlas-debug启动，默认debug端口是5005
此刻环境也运行起来了，该将我们开发的插件，部署到环境中去了，同样，重新开一个cmd先进入 我们上面建的插件的根目录 敲atlas-mvn package回车，会出现很多打包信息，还有junit测试的信息，因为必须要junti测试通过之后，才能正确打成jar包，这个junit代码，就是上面我贴图中的，test/java包里的代码，junit类也是build自动生成的，如果多次test不通过，可以直接把代码改改，通过校验，正确打包后，会出现以下界面：
打包成功后，会在插件工程的target目录（此目录里的内容同样别有一番洞天，web容器，日志，jira上的所有操作的产生的文件，等等都在这个目录里，介绍不完，大部分还算属于一个正常点web工程运行时结构，所以理解起来的话应该还是大部分能看懂的）出现jar包信息，如图
并会自动部署到tomcat里，可以看到tomcat conlose运行日志 如图：
以后如果需要重新部署的话，就执行atlas-mvn package指令就可以，当然插件本身必须要先支持热部署（默认已经是true），否则部署是无效的，修改pom.xml如下图：
当插件开发完毕，可以上正式环境的时候，就把这个不带tests的jar，通过插件管理页面上传到正式环境就可以正常使用了，这里提下可能会遇到日志可能会报一个错误，也是纠结到死，明明是SDK自动创建出来的代码，运行时居然报错，报依赖找不到：
Unsatisfied dependency expressed through constructor argument with index 0 of type [com.atlassian.jira.issue.customfields.persistence.CustomFieldValuePersister]:
这个官方也有过说明，看日志也会给你解释的访问地址，原因还是内部采用各种spring版本的兼容性问题，这里不赘述了，大概提一下，构造函数的参数上要加上@ComponentImport注解，类上要加上@ExportAsService注解
正常的话，到这里部署完毕，看看jira上面的效果吧：
三、why-为什么要开发插件？
其实，在what中已经提到了，在how中，我做了一个自定类型的字段，但是有那么多种插件类型，针对无数的场景，如果我想在某一个工作流中，想实现某一次提交后，触发另一个功能（比如，改变某个字段的值，或者调用第三方系统的rest 或者 webservcie，根据返回结果再触发下一个流程等等），这依旧是一个插件类型，上面提到过，叫做workflow post function ，开发插件是为了让我们的定制化更加深入，更加符合我们的需求。当你觉得jira现有功能，不能满足你的时候，考虑插件吧，无论是什么场景，我想都应该有对应的解决方案的。
最后，还是那句话，抛砖引玉，希望这篇文章，能给更多的刚入门的做二次开发的小伙伴们，提供一个入口，不至于像我开始那样，到处找相关的关键字，无从下手。
