博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
如何发布jar包到maven中央仓库
阅读量:5960 次
发布时间:2019-06-19

本文共 7472 字,大约阅读时间需要 24 分钟。

自使用maven以来,没少使用maven中央仓库中的各种jar包,方便有效,但是咱们也不能总是只取不予,也应该懂得奉献,当你写好了一个十分好用的jar包,想贡献出去给大家使用的时候,应该怎么做呢?当然是发布到maven的中央仓库了,不过要说这个发布过程,还真是比较复杂,本文就来详细说下如何发布jar包到maven中央仓库。 

开始之前,请注意几个地址: 
1、工单管理:

说明:注册账号、创建和管理issue,Jar包的发布是以解决issue的方式起步的

2、构件仓库:

说明:算是正式发布前的一个过段仓库,使用maven提交后的jar包先到这个库中

1、创建工单

在上述的工单管理的地址中进行创建,如果没有账号,需要先注册一个,记住用户名密码,后边要配置到setting.xml中。 

Create Issue 填写内容说明: 
Step 1

===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后,就可以进行下一步操作了,否则,就等待… 

Sonatype review

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的参数需要记住,这个相当于是是密钥的密码,下一步发布过程中进行签名操作的时候会用到。 

gpg --gen-key

4、Deploy

这步就简单了,就是一套命令:

mvn clean deploy -P sonatype-oss-release -Darguments="gpg.passphrase=密钥密码"

 

如果使用eclipse的mvn插件发布的话,配置如下: 

eclipse 
如果发布成功,就可以到构件仓库中查看了。

5、Release

进入https://oss.sonatype.org/#stagingRepositories查看发布好的构件,点击左侧的Staging Repositories,一般最后一个就是刚刚发布的jar了,此时的构件状态为open。 

打开命令行窗口,查看gpg key并上传到第三方的key验证库:

E:\98_code\workSpace\marathon-client>gpg --list-keysC:/Users/VF/AppData/Roaming/gnupg/pubring.gpg---------------------------------------------pub   2048R/824B4D7A 2016-01-06uid       [ultimate] cloudnil 
sub 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库。

第四:发布时遇到的一些问题

  1. 部署到snapshot仓库时,jar包会带上时间戳,这没关系,maven会自动取相应版本最新的jar包;
  2. 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】,不允许覆盖更新组件。

    解决办法:修改一下版本号,再提交即可。

  3.  持续更新...

https://www.cnblogs.com/yucy/p/7509561.html

 

转载于:https://www.cnblogs.com/softidea/p/6743108.html

你可能感兴趣的文章
前端每日实战:7# 视频演示如何用纯 CSS 创作一个 3D 文字跑马灯特效
查看>>
前端构建工具 -- Webpack
查看>>
几种排序算法及 Python 实现
查看>>
java后端的学习之路(一) ------ mysql和jdbc&DBUtils
查看>>
(LeetCode-数组-2) 只出现一次的数字
查看>>
基于Nginx的中间件架构(三):Rewrite规则、secure_link和Geoip读取地域信息模块、HTTPS服务...
查看>>
CSS引入外部字体方法,附可用demo
查看>>
窥探React - 源码分析
查看>>
HTML之基础介绍
查看>>
puppeteer_node爬虫分布式进阶
查看>>
Phoenix报错(2-2)AccessDeniedException: Insufficient permissions
查看>>
leetcode 605 Can Place Flowers
查看>>
JS 单例模式
查看>>
解决oninput事件在中文输入法下会取得拼音的值的问题
查看>>
Hooking & Executing Code with dlopen & dlsym -- C functions
查看>>
GitLab 安装笔记
查看>>
JavaScript 异步队列及Co实现
查看>>
原生javascript实现无缝滚动
查看>>
EventBus使用方法详解
查看>>
使用 Phoenix-4.11.0连接 Hbase 集群 ,并使用 JDBC 查询测试
查看>>