如何发布jar包到maven*仓库

时间：2022-09-29 02:23:17

自使用maven以来，没少使用maven*仓库中的各种jar包，方便有效，但是咱们也不能总是只取不予，也应该懂得奉献，当你写好了一个十分好用的jar包，想贡献出去给大家使用的时候，应该怎么做呢？当然是发布到maven的*仓库了，不过要说这个发布过程，还真是比较复杂，本文就来详细说下如何发布jar包到maven*仓库。 
开始之前，请注意几个地址： 
1、工单管理：https://issues.sonatype.org/secure/Dashboard.jspa

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

2、构件仓库：https://oss.sonatype.org/#welcome

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

1、创建工单

在上述的工单管理的地址中进行创建，如果没有账号，需要先注册一个，记住用户名密码，后边要配置到setting.xml中。 
Create Issue 填写内容说明： 
如何发布jar包到maven*仓库

===Step 1===

Project：Community Support - Open Source Project Repository Hosting

Issue Type：New Project

===Step 2===

Summary：JAR包名称，如：marathon-client

Group Id：你懂得，不用多说，如com.cloudnil

Project URL：项目站点，如：https://github.com/CloudNil/marathon-client

SCM url：项目源码仓库，如：https://github.com/CloudNil/marathon-client.git

其他内容不用填写，创建Issue后需要等待一小段时间，Sonatype的工作人员审核处理，速度还是很快的，一般一个工作日以内，当Issue的Status变为RESOLVED后，就可以进行下一步操作了，否则，就等待… 
如何发布jar包到maven*仓库

2、配置Maven

在工程的pom.xml文件中，引入Sonatype官方的一个通用配置oss-parent，这样做的好处是很多pom.xml的发布配置不需要自己配置了：

    <parent>

        <groupId>org.sonatype.oss</groupId>

        <artifactId>oss-parent</artifactId>

        <version>7</version>

    </parent>


并增加Licenses、SCM、Developers信息：




    <licenses>

        <license>

            <name>The Apache Software License, Version 2.0</name>

            <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>

            <distribution>repo</distribution>

        </license>

    </licenses>

    <scm>

        <tag>master</tag>

        <url>git@github.com:cloudnil/marathon-client.git</url>

        <connection>scm:git:git@github.com:cloudnil/marathon-client.git</connection>

        <developerConnection>scm:git:git@github.com:cloudnil/marathon-client.git</developerConnection>

    </scm>

    <developers>

        <developer>

            <name>cloudnil</name>

            <email>cloudnil@126.com</email>

            <organization>CloudNil</organization>

        </developer>

    </developers>




修改maven配置文件setting.xml，在servers中增加server配置，找不到这个文件的同学请自己去旁边哭会先。




  <servers>

    <server>

      <id>sonatype-nexus-snapshots</id>

      <username>Sonatype 账号</username>

      <password>Sonatype 密码</password>

    </server>

    <server>

      <id>sonatype-nexus-staging</id>

      <username>Sonatype 账号</username>

      <password>Sonatype 密码</password>

    </server>

  </servers>




3、配置gpg-key


如果是使用的windows，可以下载gpg4win，地址：https://www.gpg4win.org/download.html，安装后在命令行中执行 gpg --gen-key生成，过程中需要填写名字、邮箱等，其他步骤可以使用默认值，不过有个叫：Passphase的参数需要记住，这个相当于是是密钥的密码，下一步发布过程中进行签名操作的时候会用到。 
如何发布jar包到maven*仓库


4、Deploy


这步就简单了，就是一套命令：




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




如果使用eclipse的mvn插件发布的话，配置如下： 
如何发布jar包到maven*仓库 
如果发布成功，就可以到构件仓库中查看了。


5、Release


进入https://oss.sonatype.org/#stagingRepositories查看发布好的构件，点击左侧的Staging Repositories，一般最后一个就是刚刚发布的jar了，此时的构件状态为open。 
打开命令行窗口，查看gpg key并上传到第三方的key验证库：




E:\98_code\workSpace\marathon-client>gpg --list-keys

C:/Users/VF/AppData/Roaming/gnupg/pubring.gpg

---------------------------------------------

pub   2048R/824B4D7A --

uid       [ultimate] cloudnil <cloudnil@.com>

sub   2048R/7A10AD69 --

E:\98_code\workSpace\marathon-client>gpg --keyserver hkp://keyserver.ubuntu.com:11371 --send-keys 824B4D7A

gpg: sending key 824B4D7A to hkp server keyserver.ubuntu.com

E:\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: http://git-scm.com/


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_repository

scm:git:http://server_name[:port]/path_to_repository

scm:git:https://server_name[:port]/path_to_repository

scm:git:ssh://server_name[:port]/path_to_repository

scm:git:file://[hostname]/path_to_repository




  • Examples

    

    scm:git:git://github.com/path_to_repository
    
scm:git:http://github.com/path_to_repository
    
scm:git:https://github.com/path_to_repository
    
scm:git:ssh://github.com/path_to_repository
    
scm: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:

    

    <developerConnection>scm:git:[fetch=]http://mywebserver.org/path_to_repository[push=]ssh://username@otherserver:8898/~/repopath.git</developerConnection>
    

    







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.




<git-settings>

  <!-- will had the option --no-verify to the commit command can be helpfull to ignore trailing spaces issues with cygwin and the release plugin -->

  <commitNoVerify>false</commitNoVerify>

</git-settings>






http://maven.apache.org/scm/git.html


在编码过程中，有些通用的代码模块，有时候我们不想通过复制拷贝来粗暴地复用，因为这样不仅体现不了变化，也不利于统一管理。这里我们使用maven deploy的方式，将通用的模块打成jar包，发布到nexus，让其他的项目来引用，以更简洁高效的方式来实现复用和管理。


第一：maven的settings.xml文件中设置<server>标签




    <server>

      <id>my-deploy-release</id>

      <username>admin</username>

      <password>admin123</password>

    </server>

    <server>

      <id>my-deploy-snapshot</id>

      <username>admin</username>

      <password>admin123</password>

    </server>




此处设置的用户名和密码都是nexus的登陆配置


第二：在项目的pom.xml文件中设置




<distributionManagement>

    <repository>

        <id>my-deploy-release</id>

        <url>http://192.168.1.123:8081/nexus/content/repositories/releases/</url>

    </repository>

    <snapshotRepository>

        <id>my-deploy-snapshot</id>

        <url>http://192.168.1.123:8081/nexus/content/repositories/snapshots/</url>

    </snapshotRepository>

</distributionManagement>




在此，url都是nexus相应仓库的链接地址，这一步做完之后，已经完成了发布所需要的基本配置。【试试命令：mvn deploy】


注意：<server>中的<id>要和<repository>、<snapshotRepository>的<id>一致，maven在发布时，会根据此id来查找相应的用户名密码进行登录验证并上传文件。


第三：发布的灵活性配置


maven会判断版本后面是否带了-SNAPSHOT，如果带了就发布到snapshots仓库，否则发布到release仓库。这里我们可以在pom.xml文件中，设置




<groupId>com.test</groupId>

<artifactId>my-test</artifactId>

<packaging>jar</packaging>

<version>${project.release.version}</version>

<properties>

    <java.version>1.8</java.version>

    <project.release.version>1.0-SNAPSHOT</project.release.version>

</properties>

<profiles>

    <profile>

        <id>product</id>

        <properties>

            <project.release.version>1.0</project.release.version>

        </properties>

    </profile>

</profiles>




说明：通过占位符${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. 

  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. 

  3. 持续更新...
    4. 



https://www.cnblogs.com/yucy/p/7509561.html
相关文章