Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Tue, 02 Jun 2026 19:32:02 +0000 Subject: [pgjdbc/pgjdbc] issue #4142: Split "build artifacts" and "publish to Central" steps List-Id: X-GitHub-Author-Id: 213894 X-GitHub-Author-Login: vlsi X-GitHub-Issue: 4142 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-State: closed X-GitHub-Type: issue X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/4142 Content-Type: text/plain; charset=utf-8 Currently we build artifacts and publish to Central with Gradle. It has certain advantages: * One can publish with a single command: `./gradlew publishAggregationToCentralPortal -Prelease=true -PcentralPortalPublishingType=AUTOMATIC` * The build could double-check uncommitted changes (e.g. if you have uncommitted java files when publishing) It has disadvantages: * Central publication token is available to all build plugins which is quite something * If Sonatype alters publication API, the build scripts need adjustments We might alter the approach: 1. Build artifacts ( `postgresql.jar`, `-sources.jar`, `-javadoc.jar`, ...) as it was previously 2. Publish artifacts to Central with a different tool The build and publish separation would make it easier to implement sigstore signing (see https://github.com/pgjdbc/pgjdbc/issues/1267 ). We don't want to expose sigstore token to every dependency in our build script. The disadvantage of the split approach is that it would be harder to publish from a local machine. Frankly, I think the use of developer's machines for publication is insecure and it is not reproducible (e.g. there might be accidental changes when publishing), so I think the disadvantage is not significant enough. Is it something we want? Any ideas on the exact tools we should use?