Skip to content

docs: document JDK 17 build requirement and Jabel Java 8 bytecode - #920

Open
Vishal Kumar Singh (singhvishalkr) wants to merge 1 commit into
confluentinc:masterfrom
singhvishalkr:docs-906-build-jdk-jabel
Open

docs: document JDK 17 build requirement and Jabel Java 8 bytecode#920
Vishal Kumar Singh (singhvishalkr) wants to merge 1 commit into
confluentinc:masterfrom
singhvishalkr:docs-906-build-jdk-jabel

Conversation

@singhvishalkr

@singhvishalkr Vishal Kumar Singh (singhvishalkr) commented May 8, 2026

Copy link
Copy Markdown

Fixes #906.

Readers comparing
elease.target\ (8) with Mutiny were unsure how the tree compiles. The parent POM uses Java 17 sources with Jabel to emit Java 8 bytecode; IntelliJ activates a separate Maven profile.

Added a Development Information subsection in \src/docs/README_TEMPLATE.adoc\ and synced \README.adoc\ so GitHub shows it (Maven not available here to run \mvn process-sources; edits mirror what that goal emits).

Checklist

  • Documentation (if applicable)
  • Changelog

@singhvishalkr

Vishal Kumar Singh (singhvishalkr) commented May 9, 2026

Copy link
Copy Markdown
Author

Only the Confluent CLA check is visible from this fork right now. Full GitHub Actions runs still need a maintainer to add the ok-to-test label, same as earlier PRs here. No further branch change from my side.

Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Jul 28, 2026
…p findings in manifest

The 2026-07-28 activity sweep surfaced upstream items the manifest didn't have.

Reconcile confluentinc#859: upstream PR confluentinc#892 (priesus) MERGED 2025-10-27 also targets the
PCMetrics leak, but fixes a DIFFERENT cause (OffsetMapCodecManager re-instantiated
each commit, recreating meters) than our fork fix (duplicate meter re-registration
on assign/revoke). Issue confluentinc#859 is still open, so mark upstream status 'mixed' and
add a reconciliation block tracking the open questions: does the fork already
carry confluentinc#892 / conflict with it, and did confluentinc#892 actually break the master build (the
author feared so; astubbs attributed it to the io.stubbs.truth dep not being on
Maven Central, not a code regression) -- verify before relying on it. Adds a
documented optional `reconciliation` field to the schema.

Capture other new findings: confluentinc#917 kafka-clients 3.9.2 SECURITY (into the security
batch); confluentinc#918/confluentinc#919 log-noise trims as a new logging-ux entry (with confluentinc#640/confluentinc#629/confluentinc#631);
confluentinc#920 JDK 17 build-doc PR linked to the Java-baseline entry; confluentinc#902 KEY-ordering
issue as a new entry; note confluentinc#921/confluentinc#922 (fork-awareness already partly upstream) on
the maintenance-signal entry so we don't duplicate it when backlinking.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Jul 28, 2026
Cache the fork<->upstream relationship once, machine-readably, so it stops being
re-derived by hand every session. This fork (bz.stub.parallelconsumer) tracks the
effectively-archived confluentinc/parallel-consumer, whose issues/PRs are a backlog
worth mining and back-linking.

Source of truth:
- src/docs/development/upstream-map.yaml -- one entry per unit of work mapping fork
  branch/PR <-> upstream issue/PR, work group, lifecycle status
  (none|in-progress|ready|pr-open|merged|released), optional reconciliation, todo,
  and a public-facing backlink message. Header documents the schema; carries a
  last_swept date. Design follows Debian DEP-3 / Yocto Upstream-Status / OpenShift
  UPSTREAM.
- src/docs/development/upstream-pr-analysis.adoc slimmed to editorial judgement
  (rankings/verdicts/merge order) with anchors the manifest links to; the manifest
  wins for facts. docs/inflight.md points at the manifest for the durable mapping.

Tooling (scripts/):
- upstream-map.py -- validate | table | refs | show | meta | tracked | posted-refs | todo
- upstream-backlink.sh -- post a "fixed in the fork" / "maintained in a fork" comment
  to an upstream issue/PR, driven by the manifest. Dry-run by default; anti-spam:
  idempotent (skips already-forwarded), per-run cap, delay, status guard. Comment
  body comes from the entry's backlink field (single source of truth) or a template.
- upstream-sweep.sh -- read-only check for NEW upstream activity since last_swept and
  drift on tracked refs; --publish updates a single fork tracking issue.

Conventions: .gitmessage adds DEP-3-style upstream commit trailers (unforced);
AGENTS.md documents the whole system.

Seeded from the analysis doc, inflight notes, git and memory, and reconciled against
a live gh sweep -- which caught drift (upstream confluentinc#541/confluentinc#548 now closed, confluentinc#866 is Kafka
v4 not v7) and new items (confluentinc#892 merged, confluentinc#917/confluentinc#918/confluentinc#919/confluentinc#920/confluentinc#902). confluentinc#859 reconciled:
upstream confluentinc#892 fixed the per-commit meter churn; fork PR #57 fixes the tracking-List
(List->Set) plus assignment-path OffsetMapCodecManager caching.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Jul 28, 2026
Cache the fork<->upstream relationship once, machine-readably, so it stops being
re-derived by hand every session. This fork (bz.stub.parallelconsumer) tracks the
effectively-archived confluentinc/parallel-consumer, whose issues/PRs are a backlog
worth mining and back-linking.

Source of truth:
- src/docs/development/upstream-map.yaml -- one entry per unit of work mapping fork
  branch/PR <-> upstream issue/PR, work group, lifecycle status
  (none|in-progress|ready|pr-open|merged|released), optional reconciliation, todo,
  and a public-facing backlink message. Header documents the schema; carries a
  last_swept date. Design follows Debian DEP-3 / Yocto Upstream-Status / OpenShift
  UPSTREAM.
- src/docs/development/upstream-pr-analysis.adoc slimmed to editorial judgement
  (rankings/verdicts/merge order) with anchors the manifest links to; the manifest
  wins for facts. docs/inflight.md points at the manifest for the durable mapping.

Tooling (scripts/):
- upstream-map.py -- validate | table | refs | show | meta | tracked | posted-refs | todo
- upstream-backlink.sh -- post a "fixed in the fork" / "maintained in a fork" comment
  to an upstream issue/PR, driven by the manifest. Dry-run by default; anti-spam:
  idempotent (skips already-forwarded), per-run cap, delay, status guard. Comment
  body comes from the entry's backlink field (single source of truth) or a template.
- upstream-sweep.sh -- read-only check for NEW upstream activity since last_swept and
  drift on tracked refs; --publish updates a single fork tracking issue.

Conventions: .gitmessage adds DEP-3-style upstream commit trailers (unforced);
AGENTS.md documents the whole system.

Seeded from the analysis doc, inflight notes, git and memory, and reconciled against
a live gh sweep -- which caught drift (upstream confluentinc#541/confluentinc#548 now closed, confluentinc#866 is Kafka
v4 not v7) and new items (confluentinc#892 merged, confluentinc#917/confluentinc#918/confluentinc#919/confluentinc#920/confluentinc#902). confluentinc#859 reconciled:
upstream confluentinc#892 fixed the per-commit meter churn; fork PR #57 fixes the tracking-List
(List->Set) plus assignment-path OffsetMapCodecManager caching.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Antony Stubbs (astubbs) added a commit to astubbs/parallel-consumer that referenced this pull request Jul 28, 2026
Cache the fork<->upstream relationship once, machine-readably, so it stops being
re-derived by hand every session. This fork (bz.stub.parallelconsumer) tracks the
effectively-archived confluentinc/parallel-consumer, whose issues/PRs are a backlog
worth mining and back-linking.

Source of truth:
- src/docs/development/upstream-map.yaml -- one entry per unit of work mapping fork
  branch/PR <-> upstream issue/PR, work group, lifecycle status
  (none|in-progress|ready|pr-open|merged|released), optional reconciliation, todo,
  and a public-facing backlink message. Header documents the schema; carries a
  last_swept date. Design follows Debian DEP-3 / Yocto Upstream-Status / OpenShift
  UPSTREAM.
- src/docs/development/upstream-pr-analysis.adoc slimmed to editorial judgement
  (rankings/verdicts/merge order) with anchors the manifest links to; the manifest
  wins for facts. docs/inflight.md points at the manifest for the durable mapping.

Tooling (scripts/):
- upstream-map.py -- validate | table | refs | show | meta | tracked | posted-refs | todo
- upstream-backlink.sh -- post a "fixed in the fork" / "maintained in a fork" comment
  to an upstream issue/PR, driven by the manifest. Dry-run by default; anti-spam:
  idempotent (skips already-forwarded), per-run cap, delay, status guard. Comment
  body comes from the entry's backlink field (single source of truth) or a template.
- upstream-sweep.sh -- read-only check for NEW upstream activity since last_swept and
  drift on tracked refs; --publish updates a single fork tracking issue.

Conventions: .gitmessage adds DEP-3-style upstream commit trailers (unforced);
AGENTS.md documents the whole system.

Seeded from the analysis doc, inflight notes, git and memory, and reconciled against
a live gh sweep -- which caught drift (upstream confluentinc#541/confluentinc#548 now closed, confluentinc#866 is Kafka
v4 not v7) and new items (confluentinc#892 merged, confluentinc#917/confluentinc#918/confluentinc#919/confluentinc#920/confluentinc#902). confluentinc#859 reconciled:
upstream confluentinc#892 fixed the per-commit meter churn; fork PR #57 fixes the tracking-List
(List->Set) plus assignment-path OffsetMapCodecManager caching.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.

Mismatch between release.version in pom.xml and dependencies

1 participant