After several weeks of refactoring and modernizing the J2V8 build infrastructure, I’m happy to announce that J2V8 version 6.3.4 is now available on Maven Central:

<dependency>
  <groupId>com.eclipsesource.j2v8</groupId
  <artifactId>j2v8</artifactId>
  <version>6.3.4</version>
</dependency>

This release wasn’t just a version bump. It required a significant rewrite of how J2V8 assets are assembled, signed, packaged, and published. The changes span Gradle, Maven, Python build scripts, CI behavior, and V8 integration.

This post summarizes the work, the motivations behind it, and what the new publishing pipeline enables for future releases.

Why This Had to Be Done

Three big changes created a perfect storm:

1. The Maven Central publishing process changed.
   The legacy OSSRH staging repository workflow (using uploadArchives or nexus-staging-maven-plugin) no longer works with the new Maven Central Portal.

2. J2V8’s build scripts and publishing logic were outdated.
   The build system used deprecated Gradle APIs, legacy Maven plugins, and a variety of custom scripts that assumed the old Sonatype workflow.

3. The move to a newer version of V8 required modernizing the Android toolchain.
   Recent Android requirements, especially mandatory 16K page-size support, meant J2V8’s underlying V8 binaries had to be rebuilt. Once that was done, the publishing pipeline became the last remaining blocker.

The result: updating V8 forced a long overdue cleanup of the entire release system.

What I Changed

Here are the major components of the overhaul.

1. Adopt the New Maven Central Publishing Flow

Maven Central now expects releases to be uploaded as a “bundle ZIP”, with checksums, signatures, sources, javadoc, and POM metadata via HTTPS:

POST https://central.sonatype.com/api/v1/publisher/upload

To support this, I:

✔ Added the io.github.gradle-nexus.publish-plugin

This replaces deprecated publishing logic and integrates with the new central portal.

✔ Removed all OSSRH staging repository configuration

The old endpoints (e.g., oss.sonatype.org/service/local/staging/...) no longer work.

✔ Introduced modern signing behavior

Signing only activates when keys are provided, making CI/CD safer and more predictable.

2. Introduce a New j2v8publish Build Step

In the Python build orchestration (build_system/), I added a new command:

j2v8publish

This step:

1. Updates POM metadata
2. Copies the built j2v8-release.aar into the correct target structure
3. Produces GPG signatures
4. Generates checksums
5. Assembles the Central Bundle ZIP using a custom assembly descriptor
6. Uploads it to Sonatype via curl
7. Validates that the portal accepts it

This replaces the entire OSSRH staging flow with the new Central API pipeline.

3. Clean Up Artifact Metadata and Naming

J2V8 has long published multi-architecture AARs, and that remains unchanged.

What did change was:

• artifact IDs no longer contain platform-specific metadata
• the Maven + Gradle metadata is internally consistent
• the AAR, POM, javadoc, and sources JARs share the same artifact ID
• versioning is managed in one place and used consistently across scripts

This reduces accidental inconsistencies and ensures predictable consumption by build tools.

4. Modernize the Maven Build

The legacy pom.xml had to be rewritten to support the new publishing workflow.

Key updates:

✔ Add build-helper-maven-plugin to attach the AAR

✔ Add maven-assembly-plugin with a custom descriptor (central-bundle.xml)

✔ Disable legacy install and deploy phases

✔ Add fully automated signing and checksum generation

✔ Add exec-maven-plugin to upload to Sonatype’s new API

This structure matches the expectations of Maven Central Portal and ensures reproducible releases.

5. Improve Build Constants and Versioning

J2V8 now consistently tracks:

6.3.4

across:

• Gradle
• Maven
• Python build scripts
• generated POM metadata
• the final published artifact

Several small inconsistencies were fixed along the way.

6. Updated V8 Build With Android 16K Page Support

One of the main drivers behind this release was upgrading V8, and specifically:

• rebuilding V8 for Android with 16K page-size support, which is now a requirement
• updating the toolchain used in Docker builds
• aligning the Android build with modern NDK + CMake behavior

These updates required changes to how the final AAR is assembled, and triggered the need for the publishing overhaul.

What You Get Now

With all these changes applied, developers can now consume J2V8 with a single dependency:

<dependency>
  <groupId>com.eclipsesource.j2v8</groupId>
  <artifactId>j2v8</artifactId>
  <version>6.3.4</version>
</dependency>

The artifact includes all supported Android ABIs, the newly built V8 binaries, and proper Maven metadata.

The release process is now:

• automated
• aligned with the modern Maven Central infrastructure
• reproducible
• signed
• CI-friendly
• maintainable

What’s Next

Now that publishing is fixed, the next steps become much easier:

• Regular V8 updates
• AGP 8 and Gradle 8 compatibility
• Better testing on real Android hardware
• Exploring additional platform support (e.g., macOS ARM64)
• Improving the JNI layer stability and documentation

With the release pipeline fully unblocked, development can move forward again.

Final Thoughts

This release required:

• Gradle plugin modernization
• Maven restructuring
• A new multi-step publishing pipeline
• Updated build constants
• New signing and checksum logic
• Adoption of the Maven Central Portal API
• Multiple fixes across build scripts, Python utilities, and POMs
• Rebuilding V8 to meet Android’s modern requirements

But the result is a much cleaner, more maintainable, and future-proof J2V8 distribution.

If you’re using J2V8 today, upgrading to 6.3.4 is strongly recommended.

If you run into issues or have ideas for improvements, please open an issue on GitHub, now that the publishing workflow is solved, new releases will be much easier to produce.