向 Maven 中央仓库上传一个修改过的基于jeecg的autoPOI的 jar包记录(二)

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 向 Maven 中央仓库上传一个修改过的基于jeecg的autoPOI的 jar包记录

向 Maven 中央仓库上传一个修改过的基于jeecg的autoPOI的 jar包记录(一)+https://developer.aliyun.com/article/1505051

Distribution Management and Authentication⚓︎

In order to configure Maven to deploy to the OSSRH Nexus Repository Manager with the Nexus Staging Maven plugin you have to configure it like this

Note: As of February 2021, all new projects began being provisioned on Nexus Repository Manager. If your project is not provisioned on Nexus Repository Manager, you will want to login to the legacy host Nexus Repository Manager.

<distributionManagement>
  <snapshotRepository>
    <id>ossrh</id>
    <url>https://s01.oss.sonatype.org/content/repositories/snapshots</url>
  </snapshotRepository>
</distributionManagement>
<build>
  <plugins>
    <plugin>
      <groupId>org.sonatype.plugins</groupId>
      <artifactId>nexus-staging-maven-plugin</artifactId>
      <version>1.6.7</version>
      <extensions>true</extensions>
      <configuration>
        <serverId>ossrh</serverId>
        <nexusUrl>https://s01.oss.sonatype.org/</nexusUrl>
        <autoReleaseAfterClose>true</autoReleaseAfterClose>
      </configuration>
    </plugin>
    ...
  </plugins>
</build>

Since OSSRH is always running the latest available version of Sonatype Nexus Repository Manager, it is best to use the latest version of the Nexus Staging Maven plugin.

Alternatively if you are using the Maven deploy plugin, which is the default behavior, you need to add a full distributionManagement section.

<distributionManagement>
  <snapshotRepository>
    <id>ossrh</id>
    <url>https://s01.oss.sonatype.org/content/repositories/snapshots</url>
  </snapshotRepository>
  <repository>
    <id>ossrh</id>
    <url>https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/</url>
  </repository>
</distributionManagement>

The above configurations will get the user account details to deploy to OSSRH from your Maven settings.xml file, usually placed in ~/.m2. A minimal settings with the authentication is:

<settings>
  <servers>
    <server>
      <id>ossrh</id>
      <username>your-jira-id</username>
      <password>your-jira-pwd</password>
    </server>
  </servers>
</settings>

Note how the id element in the server element in settings.xml is identical to the id elements in the snapshotRepository and repository element as well as the serverId configuration of the Nexus Staging Maven plugin

Javadoc and Sources Attachments⚓︎

To get Javadoc and Source jar files generated, you have to configure the Javadoc and source Maven plugins.

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-source-plugin</artifactId>
      <version>2.2.1</version>
      <executions>
        <execution>
          <id>attach-sources</id>
          <goals>
            <goal>jar-no-fork</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-javadoc-plugin</artifactId>
      <version>2.9.1</version>
      <executions>
        <execution>
          <id>attach-javadocs</id>
          <goals>
            <goal>jar</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

GPG Signed Components⚓︎

The Maven GPG plugin is used to sign the components with the following configuration.

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-gpg-plugin</artifactId>
      <version>1.5</version>
      <executions>
        <execution>
          <id>sign-artifacts</id>
          <phase>verify</phase>
          <goals>
            <goal>sign</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

It relies on the gpg command being installed and the GPG credentials being available e.g. from settings.xml. In addition you can configure the gpg command in case it is different from gpg. This is a common scenario on some operating systems.

<settings>
  <profiles>
    <profile>
      <id>ossrh</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <gpg.executable>gpg2</gpg.executable>
        <gpg.passphrase>the_pass_phrase</gpg.passphrase>
      </properties>
    </profile>
  </profiles>
</settings>

In case you have multiple keys, the local gpg will use the first listed signature key (gpg --list-signatures), if you need to use a specific key you could add the details of the gpg key inside a <configuration> section and use local settings.xml to discover the passphrase via the signature keyname.

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-gpg-plugin</artifactId>
      <version>1.5</version>
      <executions>
        <execution>
          <id>sign-artifacts</id>
          <phase>verify</phase>
          <goals>
            <goal>sign</goal>
          </goals>
          <configuration>
            <keyname>${gpg.keyname}</keyname>
            <passphraseServerId>${gpg.keyname}</passphraseServerId>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Are you being prompted for a passphrase or getting a gpg: signing failed: No such file or directory error?

This may be happening to you because you are using gpg version 2.1 or later. If running gpg --version shows that you are running version 2.1 or later, you must modify the configuration of the Maven GPG plugin to add additional gpgArguments. Building on the example above:

<configuration>
  <keyname>${gpg.keyname}</keyname>
  <passphraseServerId>${gpg.keyname}</passphraseServerId>
  <gpgArguments>
    <arg>--pinentry-mode</arg>
    <arg>loopback</arg>
  </gpgArguments>
</configuration>

Hint

In the example below you may need to use the last 8 characters of the signature keyid in hexadecimal format, you can find them using this command gpg --list-signatures --keyid-format 0xshort:

$ gpg --list-signatures --keyid-format 0xshort
/home/mylocaluser/.gnupg/pubring.kbx
---------------------------------
pub   rsa3072/0x3ABDEC12 2021-01-27 [SC] [expires: 2023-01-27]
      74524542545300A398653AB5242798823ABDEC12
uid           [ultimate] Other Name <otheremail@example.com>
sig 3        0x3ABDEC12 2021-01-27  Other Name <alarconj@gmail.com>
sub   rsa3072 2021-01-27 [E] [expires: 2023-01-27]
sig          0x3ABDEC12 2021-01-27  Julian Alarcon <alarconj@gmail.com>
pub   rsa3072/0x0ABA0F98 2021-06-23 [SC] [expires: 2022-03-21]
      CA925CD6C9E8D064FF05B4728190C4130ABA0F98
uid           [ultimate] Central Repo Test <central@example.com>
sig 3        0x0ABA0F98 2021-06-24  Central Repo Test <central@example.com>
sub   rsa3072/0x7C17C93B 2021-06-23 [E] [expires: 2023-06-23]
sig          0x0ABA0F98 2021-06-23  Central Repo Test <central@example.com>

You will find in the line that starts with sig 3 that 0x3ABDEC12 is the signature short keyid in hexadecimal format that you will need to pass as ${gpg.keyname}.

If you need more help setting up and configuring GPG, please read our detailed instructions.

Nexus Staging Maven Plugin for Deployment and Release⚓︎

The Nexus Staging Maven Plugin is the recommended way to deploy your components to OSSRH and release them to the Central Repository. To configure it simply add the plugin to your Maven pom.xml.

<build>
<plugins>
...
<plugin>
  <groupId>org.sonatype.plugins</groupId>
  <artifactId>nexus-staging-maven-plugin</artifactId>
  <version>1.6.7</version>
  <extensions>true</extensions>
  <configuration>
     <serverId>ossrh</serverId>
     <nexusUrl>https://s01.oss.sonatype.org/</nexusUrl>
     <autoReleaseAfterClose>true</autoReleaseAfterClose>
  </configuration>
</plugin>

If your version is a release version (does not end in -SNAPSHOT) and with this setup in place, you can run a deployment to OSSRH and an automated release to the Central Repository with the usual:

mvn clean deploy

With the property autoReleaseAfterClose set to false you can manually inspect the staging repository in the Nexus Repository Manager and trigger a release of the staging repository later with

mvn nexus-staging:release

If you find something went wrong you can drop the staging repository with

mvn nexus-staging:drop

Please read Staging Releases in the Repository Manager 2 documentation for more information about the Nexus Staging Maven Plugin.

Deprecated oss-parent⚓︎

In the past all the plugin configuration and other setup was managed by a Maven parent POM with the latest coordinates of org.sonatype.oss:oss-parent:9. This project leaked SCM, URL and other details and its usage is discouraged. Maintenance of the project has stopped and it no longer works with latest tooling such as Maven versions or Java versions. If desired, please manage your own organization-level POM in a similar manner.

Using a Profile⚓︎

Since the generation of the javadoc and source jars as well as signing components with GPG is a fairly time consuming process, these executions are typically isolated from the normal build configuration and moved into a profile. This profile is then in turn used when a deployment is performed by activating the profile.

<profiles>
  <profile>
    <id>release</id>
    <build>
      ...
      javadoc, source and gpg plugin from above
      ...
    </build>
  </profile>
</profiles>

Performing a Snapshot Deployment⚓︎

Snapshot deployment are performed when your version ends in -SNAPSHOT . You do not need to fulfill the requirements when performing snapshot deployments and can simply run

mvn clean deploy

on your project.

SNAPSHOT versions are not synchronized to the Central Repository. If you wish your users to consume your SNAPSHOT versions, they would need to add the snapshot repository to their Nexus Repository Manager, settings.xml, or pom.xml. Successfully deployed SNAPSHOT versions will be found in Index of /repositories/snapshots

Performing a Release Deployment⚓︎

In order to perform a release deployment you have to edit your version in all your POM files to use release versions. This means that they can not end in -SNAPSHOT In addition plugin and dependency declarations can also not use snapshot versions. This ensures that you only depend on other released components. Ideally they are all available in the Central Repository. This ensures that your users can retrieve your components as well as your transitive dependencies from the Central Repository.

The change of the versions for your project, and the parent references in a multi module setup, can be performed manually or with the help of the Maven versions plugin.

mvn versions:set -DnewVersion=1.2.3

Once you have updated all the versions and ensured that your build passes without deployment you can perform the deployment with the usage of the release profile with

mvn clean deploy -P release

This process is completely independent from your workflow with your SCM system. If you want to ensure that a specific version in the Central Repository corresponds to a specific revisions in your SCM system, which is a good practice, you can either perform the commits manually in a flow similar to

  • Develop, develop, develop
  • Commit any outstanding changes
  • Verify build passes
  • Update versions to release version
  • Commit release version
  • Run deployment
  • Update versions to next snapshot version
  • Commit new snapshot version
  • Develop, develop, develop and rinse and repeat

or you can automate it with a script of your choice including a configuration running on a CI server or you can use the Maven release plugin, documented in the following.

Performing a Release Deployment with the Maven Release Plugin⚓︎

The Maven Release Plugin can be used to automate the changes to the Maven POM files, sanity checks, the SCM operations required and the actual deployment execution.

The configuration for the Maven release plugin should include disabling the release profile that is part of the Maven Super POM, since we are using our own profile, and specify the deploy goal together with the activation of our release profile

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-release-plugin</artifactId>
  <version>2.5.3</version>
  <configuration>
    <autoVersionSubmodules>true</autoVersionSubmodules>
    <useReleaseProfile>false</useReleaseProfile>
    <releaseProfiles>release</releaseProfiles>
    <goals>deploy</goals>
  </configuration>
</plugin>

With the SCM connection configured correctly you can perform a release deployment to OSSRH with

mvn release:clean release:prepare

by answering the prompts for versions and tags, followed by

mvn release:perform

This execution will deploy to OSSRH and release to the Central Repository in one go, thanks to the usage of the Nexus Staging Maven Plugin with autoReleaseAfterClose set to true.

Manually Releasing the Deployment to the Central Repository⚓︎

If you are using autoReleaseAfterClose set to false you or you are using the default Maven deploy plugin, you can inspect and potentially release the deployed artifacts manually

Alternatively if you have deployed with the Nexus Staging Maven Plugin, and the deployment succeeded, you can release the repository directly on the command line. Immediately after the deployment a properties file in the target directory contains all the information required and you can simply release the staging repository with

mvn nexus-staging:release

If you have been running the deployment as part of a release done with the Maven release plugin, the deployment was done from the tag in your version control system checked out into target/checkout so you have to run the Nexus Staging plugin from there:

mvn release:perform
...
cd target/checkout
mvn nexus-staging:release

You can configure this goal to be run automatically as part of your release deployment with the release plugin by adding it as a goal execution after deploy.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-release-plugin</artifactId>
  <configuration>
    <goals>deploy nexus-staging:release</goals>
    ...
相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
19天前
|
Java jenkins 持续交付
Java项目jar包启动脚本,适用jenkins或定时任务或手动执行
Java项目jar包启动脚本,适用jenkins或定时任务或手动执行
|
4天前
|
druid Java Maven
杨校老师课堂之java_关于如何下载jar包的教程
杨校老师课堂之java_关于如何下载jar包的教程
14 0
|
7天前
|
消息中间件 资源调度 Java
实时计算 Flink版操作报错合集之遇到了缺少包的错误,已经添加了相应的 jar 包,仍然出现同样的报错,该怎么解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
546 2
|
9天前
|
Oracle 关系型数据库 Java
实时计算 Flink版产品使用问题之源码 deploy,生成带有时间戳的jar包,如何修改配置信息
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
10天前
|
Java 关系型数据库 Maven
SpringBootWebProject学习4、maven打war包
SpringBootWebProject学习4、maven打war包
14 1
|
15天前
|
存储 DataWorks 安全
DataWorks产品使用合集之jar包格式是什么
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
20 6
|
15天前
|
SQL DataWorks 监控
DataWorks产品使用合集之如何创建一个函数并使用JAR包里面的方法
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
20 3
|
18小时前
|
Java Maven
Maven项目打包成jar项目后运行报错误: 找不到或无法加载主类 Main.Main 和 jar中没有主清单属性解决方案
Maven项目打包成jar项目后运行报错误: 找不到或无法加载主类 Main.Main 和 jar中没有主清单属性解决方案
8 0
|
18小时前
|
缓存 Java Maven
IDEA如何把MAVEN项目打包成jar包并且用命令行启动
IDEA如何把MAVEN项目打包成jar包并且用命令行启动
8 0
|
4天前
|
Java 数据库连接 Spring
杨校老师课堂之Java EE框架SSM所需jar包下载
杨校老师课堂之Java EE框架SSM所需jar包下载
12 0

热门文章

最新文章

推荐镜像

更多