[Split 1/3] Restructure modules: java/android → core/core-android under io.ably.pubsub

[umair-ably]

First of a stack of PRs applying PDR-091b (PubSub device/server package split, major releases) to this repo, targeting the long-lived integration/v2 branch. Reference implementation: ably-js#2293.

What this PR does

• java → core: publishes io.ably.pubsub:core (jar, JVM) — was io.ably:ably-java.
• android → core-android: publishes io.ably.pubsub:core-android (aar) — was io.ably:ably-android.
• GROUP=io.ably.pubsub, VERSION_NAME=2.0.0: everything the repo publishes moves to the new group and major in lockstep (liveobjects, pubsub-adapter, network-client-* ride along, per the rollout plan).
• Both core POMs declare themselves internal implementation artifacts for Ably's own device/server packages, not for direct use (per PDR-091b §1).
• liveobjects, pubsub-adapter, uts, examples retarget project(":java"/":android") → ":core"/":core-android"; integration-test.yml, emulate.yml, javadoc.yml, CONTRIBUTING.md and uts/README.md follow.
• Pure git mv for the module directories — history follows.

What this PR deliberately does not do

• No door packages yet — io.ably.pubsub:device / io.ably.pubsub:server land in the next PR in the stack.
• No repo rename, no publishing, no API renames (⚠️ PDR-091d is still in review).
• The core keeps the ably-java/<version> base agent identifier (matching ably-js, whose core keeps ably-js/<version>); side-declaring agents are stamped by the door packages (next PR).
• io.ably:ably-java / io.ably:ably-android 1.x are never published from this branch; fixes ship from a maintenance branch cut before the integration merge.

Notes for reviewers

• The Java package namespace (io.ably.lib.*) is unchanged in the cores for now — the namespace decision (new pubsub root package vs. documented classpath-collision hazard) and the ⚠️091d Rest*→Http* pass are deliberately sequenced later on the integration branch.
• core-android/src/main/resources/META-INF/io/ably/ably-android/verification.properties still carries the verification token issued for io.ably:ably-android — a new token for the new artifact id needs requesting before GA (tracked in the rollout plan).
• deploy/check-archives.sh was already stale (greps a build.gradle that no longer exists); untouched here.

Verified locally: checkWithCodenarc checkstyleMain checkstyleTest runUnitTests runLiveObjectsUnitTests :uts:runUtsUnitTests green; :core-android:compileReleaseJavaWithJavac green; publishToMavenLocal produces the expected io/ably/pubsub/{core,core-android,liveobjects,pubsub-adapter,network-client-*}/2.0.0 coordinates.

🤖 Generated with Claude Code

[paddybyers]

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

[umair-ably]

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

afaict, you declare one dependency, io.ably.pubsub:server, and Maven/Gradle resolves io.ably.pubsub:core transitively

[paddybyers]

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

afaict, you declare one dependency, io.ably.pubsub:server, and Maven/Gradle resolves io.ably.pubsub:core transitively

That's true, but why is it necessary? What's the problem with having a single server artifact that contains the server and core java packages?

[umair-ably]

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

afaict, you declare one dependency, io.ably.pubsub:server, and Maven/Gradle resolves io.ably.pubsub:core transitively

That's true, but why is it necessary? What's the problem with having a single server artifact that contains the server and core java packages?

If I'm understanding correctly, you're suggesting we solely have just 2 packages - device and server, and each of these have "core" embedded in them.

There's a couple reasons having core live outside works better imo...

1. As answered above, transitive package handling means the end users don't need to know about core anyway
2. Other products that build on a pubsub realtime client e.g. Chat, can work with either the device or server pubsub package, but they need a shared understanding of what that realtime interface is. The core split keeps that shared understanding between them. Another solution would be that Chat itself declares the interface it needs, but this gets into the realms of type erasure and inverting how this model works today.
3. There are packages that should be neutral e.g. LiveObjects. We currently just pass in a LiveObjects plugin without needing to declare device or server (hence the DR's decision of it being okay for internal dependencies to rely on core). If we bundled Core into the device and server packages, LiveObjects would need to identify as one or the other which breaks the mental model for how it works

I've been speaking with @AndyTWF about this too, so happy for us 3 to jump on a call if we need to

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}