自使用maven以来,没少使用maven中央仓库中的各种jar包,方便有效,但是咱们也不能总是只取不予,也应该懂得奉献,当你写好了一个十分好用的jar包,想贡献出去给大家使用的时候,应该怎么做呢?当然是发布到maven的中央仓库了,不过要说这个发布过程,还真是比较复杂,本文就来详细说下如何发布jar包到maven中央仓库。
开始之前,请注意几个地址: 1、工单管理:说明:注册账号、创建和管理issue,Jar包的发布是以解决issue的方式起步的
2、构件仓库:
说明:算是正式发布前的一个过段仓库,使用maven提交后的jar包先到这个库中
1、创建工单
在上述的工单管理
的地址中进行创建,如果没有账号,需要先注册一个,记住用户名密码,后边要配置到setting.xml
中。
===Step 1===Project:Community Support - Open Source Project Repository HostingIssue Type:New Project===Step 2===Summary:JAR包名称,如:marathon-clientGroup Id:你懂得,不用多说,如com.cloudnilProject URL:项目站点,如:https://github.com/CloudNil/marathon-clientSCM url:项目源码仓库,如:https://github.com/CloudNil/marathon-client.git
其他内容不用填写,创建Issue后需要等待一小段时间,Sonatype的工作人员审核处理,速度还是很快的,一般一个工作日以内,当Issue的Status变为RESOLVED后,就可以进行下一步操作了,否则,就等待…
2、配置Maven
在工程的pom.xml文件中,引入Sonatype官方的一个通用配置oss-parent
,这样做的好处是很多pom.xml的发布配置不需要自己配置了:
org.sonatype.oss oss-parent 7
并增加Licenses、SCM、Developers信息:
The Apache Software License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0.txt repo master git@github.com:cloudnil/marathon-client.git scm:git:git@github.com:cloudnil/marathon-client.git scm:git:git@github.com:cloudnil/marathon-client.git cloudnil cloudnil@126.com CloudNil
修改maven配置文件setting.xml,在servers中增加server配置,找不到这个文件的同学请自己去旁边哭会先。
sonatype-nexus-snapshots Sonatype 账号 Sonatype 密码 sonatype-nexus-staging Sonatype 账号 Sonatype 密码
3、配置gpg-key
如果是使用的windows,可以下载gpg4win,地址:https://www.gpg4win.org/download.html
,安装后在命令行中执行 gpg --gen-key
生成,过程中需要填写名字、邮箱等,其他步骤可以使用默认值,不过有个叫:Passphase的参数需要记住,这个相当于是是密钥的密码,下一步发布过程中进行签名操作的时候会用到。
4、Deploy
这步就简单了,就是一套命令:
mvn clean deploy -P sonatype-oss-release -Darguments="gpg.passphrase=密钥密码"
如果使用eclipse的mvn插件发布的话,配置如下:
如果发布成功,就可以到构件仓库中查看了。5、Release
进入https://oss.sonatype.org/#stagingRepositories
查看发布好的构件,点击左侧的Staging Repositories
,一般最后一个就是刚刚发布的jar了,此时的构件状态为open
。
E:\98_code\workSpace\marathon-client>gpg --list-keysC:/Users/VF/AppData/Roaming/gnupg/pubring.gpg---------------------------------------------pub 2048R/824B4D7A 2016-01-06uid [ultimate] cloudnilsub 2048R/7A10AD69 2016-01-06E:\98_code\workSpace\marathon-client>gpg --keyserver hkp://keyserver.ubuntu.com:11371 --send-keys 824B4D7Agpg: sending key 824B4D7A to hkp server keyserver.ubuntu.comE:\98_code\workSpace\marathon-client>
回到https://oss.sonatype.org/#stagingRepositories,选中刚才发布的构件,并点击上方的close–>Confirm,在下边的Activity选项卡中查看状态,当状态变成closed后,执行Release–>Confirm,并在下边的Activity选项卡中查看状态,成功后构件自动删除,一小段时间(约1-2个小时)后即可同步到maven的中央仓库。
http://blog.csdn.net/tiger435/article/details/50470316
https://www.iteblog.com/archives/1807.html
SCM Implementation: Git
General Info
Link:
License: GNU General Public License v2
SCM URL
For all URLs below, we use a colon (:) as separator. If you use a colon for one of the variables (e.g. a windows path), then use a pipe (|) as separator. The separator for the port has to be a colon in any case since this part is specified in the git URL specification. See man git-fetch.
scm:git:git://server_name[:port]/path_to_repositoryscm:git:http://server_name[:port]/path_to_repositoryscm:git:https://server_name[:port]/path_to_repositoryscm:git:ssh://server_name[:port]/path_to_repositoryscm:git:file://[hostname]/path_to_repository
- Examples
scm:git:git://github.com/path_to_repositoryscm:git:http://github.com/path_to_repositoryscm:git:https://github.com/path_to_repositoryscm:git:ssh://github.com/path_to_repositoryscm:git:file://localhost/path_to_repository
Different Fetch and Push URLs
In some cases a different URL has to be used for read and write operations. This can happen if e.g. fetch is performed via the http protocol, but writing to the repository is only possible via ssh. In this case both URLs may be written into the developerConnection tag. The fetch URL has to be prefixed with [fetch=] and the push URL with [push=]
- Example:
scm:git:[fetch=]http://mywebserver.org/path_to_repository[push=]ssh://username@otherserver:8898/~/repopath.git
Working with branches
Since version 1.3, we assume that the name of the branch in the upstream repo is the same as the name of the current local branch. So whenever you invoke a maven-scm action which has to access the upstream repository, e.g. start a release, you should be on that very branch.
In other words: If no branch is specified manually, every git-fetch, git-pull, git-push, etc will always work on the branch in the upstream repository which has the same branch name as your current local branch
git push pushUrl currentBranch:currentBranch
Provider Configuration
The provider configuration is defined in $user.home/.scm/git-settings.xml.
false
http://maven.apache.org/scm/git.html
在编码过程中,有些通用的代码模块,有时候我们不想通过复制拷贝来粗暴地复用,因为这样不仅体现不了变化,也不利于统一管理。这里我们使用maven deploy的方式,将通用的模块打成jar包,发布到nexus,让其他的项目来引用,以更简洁高效的方式来实现复用和管理。
第一:maven的settings.xml文件中设置<server>标签
my-deploy-release admin admin123 my-deploy-snapshot admin admin123
此处设置的用户名和密码都是nexus的登陆配置
第二:在项目的pom.xml文件中设置
my-deploy-release http://192.168.1.123:8081/nexus/content/repositories/releases/ my-deploy-snapshot http://192.168.1.123:8081/nexus/content/repositories/snapshots/
在此,url都是nexus相应仓库的链接地址,这一步做完之后,已经完成了发布所需要的基本配置。【试试命令:mvn deploy】
注意:<server>中的<id>要和<repository>、<snapshotRepository>的<id>一致,maven在发布时,会根据此id来查找相应的用户名密码进行登录验证并上传文件。
第三:发布的灵活性配置
maven会判断版本后面是否带了-SNAPSHOT,如果带了就发布到snapshots仓库,否则发布到release仓库。这里我们可以在pom.xml文件中,设置
com.test my-test jar ${project.release.version} 1.8 1.0-SNAPSHOT product 1.0
说明:通过占位符${project.release.version}来控制需要发布的版本,用命令mvn deploy -P product,发布my-test的1.0版本到releases库。如果使用命令mvn deploy,则默认使用 1.0-SNAPSHOT版本号,将发布my-test的1.0-SNAPSHOT版本到snapshots库。
第四:发布时遇到的一些问题
- 部署到snapshot仓库时,jar包会带上时间戳,这没关系,maven会自动取相应版本最新的jar包;
- Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project my-test: Failed to deploy artifacts: Could not transfer artifact...from/to release...
部署到release仓库时,相同版本的jar包不能提交。
原因:因为release的部署策略是【disable redeploy】,不允许覆盖更新组件。
解决办法:修改一下版本号,再提交即可。
-
持续更新...
https://www.cnblogs.com/yucy/p/7509561.html