Skip to content

Conversation

@ajantha-bhat
Copy link
Member

Add support for publishing artifacts to Apache Nexus repository with proper Maven Central metadata and signing capabilities.

Changes:

  • Add nexus-publish-plugin to root build.gradle.kts with Apache repository configuration supporting both environment variables (ASF_USERNAME, ASF_PASSWORD) and Gradle properties
  • Create publishing.kt with Maven publication setup including:
    • Proper POM metadata (licenses, SCM, mailing lists, issue tracking)
    • Support for publishing shadow JARs (CLI module)
    • Conditional signing for release builds (-Prelease flag)
    • Source and Javadoc JAR generation for non-shadow modules
  • Configure build-conventions to apply publishing to all projects
  • Update CLI module to apply shadow plugin

The configuration supports:

  • Local testing: ./gradlew publishToMavenLocal
  • Apache release: ./gradlew publishToApache -Prelease -PuseGpgAgent
  • Staging management: ./gradlew closeAndReleaseApacheStagingRepository

Published artifacts:

  • org.apache.polaris.tools:iceberg-catalog-migrator-api (with sources, javadoc)
  • org.apache.polaris.tools:iceberg-catalog-migrator-api-test (with sources, javadoc)
  • org.apache.polaris.tools:iceberg-catalog-migrator-cli (shadow JAR)

Add support for publishing artifacts to Apache Nexus repository with
proper Maven Central metadata and signing capabilities.

Changes:
- Add nexus-publish-plugin to root build.gradle.kts with Apache
  repository configuration supporting both environment variables
  (ASF_USERNAME, ASF_PASSWORD) and Gradle properties
- Create publishing.kt with Maven publication setup including:
  * Proper POM metadata (licenses, SCM, mailing lists, issue tracking)
  * Support for publishing shadow JARs (CLI module)
  * Conditional signing for release builds (-Prelease flag)
  * Source and Javadoc JAR generation for non-shadow modules
- Configure build-conventions to apply publishing to all projects
- Update CLI module to apply shadow plugin

The configuration supports:
- Local testing: ./gradlew publishToMavenLocal
- Apache release: ./gradlew publishToApache -Prelease -PuseGpgAgent
- Staging management: ./gradlew closeAndReleaseApacheStagingRepository

Published artifacts:
- org.apache.polaris.tools:iceberg-catalog-migrator-api (with sources, javadoc)
- org.apache.polaris.tools:iceberg-catalog-migrator-api-test (with sources, javadoc)
- org.apache.polaris.tools:iceberg-catalog-migrator-cli (shadow JAR)
@ajantha-bhat
Copy link
Member Author

Can I please get a review on this?
Maybe @snazy , @pingtimeout

Copy link
Member

@snazy snazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a bunch of independent projects in polaris-tools, so I think it's better to change the group-ID to org.apache.polaris.tools.iceberg-catalog-migrator so it has it's "own namespace" that doesn't conflict with other tools.

I don't see that the signing-extension (the signatory) being configured - neither with a secret-key/password combination nor via the optional useGpgAgent project property.

Changes:
1. Change group ID from 'org.apache.polaris.tools' to
   'org.apache.polaris.tools.iceberg-catalog-migrator' to give it its own
   namespace and avoid conflicts with other tools in polaris-tools

2. Configure signing extension properly following Apache Polaris main repo pattern:
   - Support both in-memory PGP keys (signingKey/signingPassword properties)
   - Support gpg-agent (useGpgAgent property)
   - Enable signing with either 'release' or 'signArtifacts' property

3. Update license name to use SPDX identifier 'Apache-2.0'
@ajantha-bhat
Copy link
Member Author

@snazy: Thanks a lot for the review.

We have a bunch of independent projects in polaris-tools, so I think it's better to change the group-ID to org.apache.polaris.tools.iceberg-catalog-migrator so it has it's "own namespace" that doesn't conflict with other tools.

That makes sense — having a distinct namespace per tool is reasonable.
To stay aligned with Apache and Java package conventions, would you be open to using a dot-separated subgroup instead, e.g. org.apache.polaris.tools.iceberg.catalog.migrator, with iceberg-catalog-migrator remaining as the artifactId?

I don't see that the signing-extension (the signatory) being configured - neither with a secret-key/password combination nor via the optional useGpgAgent project property.

Done. And verified Signing with new options.

@snazy
Copy link
Member

snazy commented Jan 26, 2026

I'd prefer a org.apache.polaris.tools.<tool-directory-name> convention for the group ID.
BTW: There's no convention for group IDs in Apache beside that it has to start with org.apache.<project-name>..

Comment on lines +94 to +95
username.set(System.getenv("ASF_USERNAME") ?: findProperty("asfNexusUsername") as String?)
password.set(System.getenv("ASF_PASSWORD") ?: findProperty("asfNexusPassword") as String?)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This introduces a new, different way from how the creds are passed in the main Polaris repo, can you please align with that and use the same names.

delayBetween.set(java.time.Duration.ofSeconds(10))
}
repositories {
create("apache") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
create("apache") {
register("apache") {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants