Setup JReleaser automation with Apache License 2.0

[Copilot]

Setup JReleaser GitHub automation for the Netty VirtualThread Scheduler project.

Summary

This PR adds complete JReleaser automation for releasing the Netty VirtualThread Scheduler project. The branch has been rebased over master for a clean linear history.

✅ Apache License 2.0

• License already added by master (uses "The Netty VirtualThread Scheduler Project" header format)
• POM updated with license metadata, SCM info, developers

✅ JReleaser Configuration

• Configured for Maven Central deployment
• Only netty-virtualthread-core artifact published to Maven
• GitHub releases with automated changelog generation
• Post-release SNAPSHOT version bumping

✅ GitHub Actions Workflow

• Manual release trigger via workflow_dispatch
• Complete automation: build → sign → deploy → release → version bump
• Proper permissions and secret management

✅ Documentation

• Comprehensive RELEASE.md with setup instructions
• Updated README with quick start guide
• Troubleshooting and support information

✅ Rebased over Master

• Clean linear history without merge commits
• All JReleaser commits properly rebased on latest master
• Updated to latest dependencies (Netty 4.2.9, JUnit 6.0.1, Java 27)

Requirements Met

• Manual release workflow trigger
• Only core artifact published to Maven
• JReleaser handles SNAPSHOT renaming for all artifacts
• Apache License 2.0 (via master's implementation)
• Clean linear history (rebased over master)

Validation Results

• ✅ POM validation passes
• ✅ JReleaser configuration validated
• ✅ No conflicts remaining
• ✅ Build successful with latest dependencies

Usage

See RELEASE.md for detailed setup instructions. Quick start:

1. Configure GitHub secrets (MAVEN_USERNAME, MAVEN_PASSWORD, GPG keys)
2. Go to Actions → Release workflow
3. Enter version and run
4. Workflow handles everything automatically

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Setup jreleaser GitHub automation</issue_title>
<issue_description>I would like to have setup to:

• publish a new release via GitHub action
• the release to maven should be just of the core artifact
• jreleaser should take care of renaming to snapshot all the artifacts (not just core)
• the release need to happen via manually triggering the action
  </issue_description>

<agent_instructions>I would like to provide the src under apache licence too</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Setup jreleaser GitHub automation #43

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[franz1981]

@copilot do you suggest me to first get all the secrets required and paste it here so you can fix it before merging or...?
How do you think I should proceed to give this a shot?

[Copilot]

@copilot do you suggest me to first get all the secrets required and paste it here so you can fix it before merging or...?
How do you think I should proceed to give this a shot?

I recommend testing without sharing secrets:

Safe Testing Approach:

1. Merge first - The workflow won't run automatically (it's workflow_dispatch only)
2. Set up secrets in your repository Settings → Secrets and variables → Actions:
   • MAVEN_USERNAME / MAVEN_PASSWORD (from https://s01.oss.sonatype.org/)
   • GPG_PRIVATE_KEY / GPG_PASSPHRASE / GPG_PUBLIC_KEY (see RELEASE.md for generation commands)
3. Test with a pre-release version like 0.1.0-RC1 or 1.0.0-test to avoid polluting your release history
4. If it fails, you can simply:
   • Delete the test tag: git push --delete origin v0.1.0-RC1
   • Delete the GitHub release in the Releases page
   • Drop the staging repo at https://s01.oss.sonatype.org/ (if it got that far)

Don't share secrets - they give full access to publish under your Maven coordinates and sign with your identity.

Alternative: Dry-run test (before merging):
If you want to validate the workflow logic first, you could temporarily add a test job that skips GPG/Maven steps and just validates the version bumping logic. But the full end-to-end test will need the real secrets anyway.

The workflow is standard JReleaser setup - low risk of issues. Main things to verify: secrets are correct format and your Sonatype account has publish rights to io.netty.loom.

[franz1981]

Thanlks @copilot so you undraft yourself once happy and I can merge it?

[Copilot]

Thanlks @copilot so you undraft yourself once happy and I can merge it?

The PR is complete and ready for merge. All requirements have been implemented and validated:

✅ Manual release workflow via GitHub Actions
✅ Only netty-virtualthread-core publishes to Maven Central
✅ All modules auto-bump to SNAPSHOT post-release
✅ Apache License 2.0 applied to all source files
✅ Complete documentation (RELEASE.md + README.md)
✅ No security vulnerabilities (CodeQL: 0 alerts)

You'll need to mark it as ready for review yourself (I can't change the draft status). Once you merge and set up the secrets in your repository settings, the release workflow will be ready to use.

[franz1981]

There are other changes in the existing modules which would help artifact versioning from jreleaser? or it's fine as it is?

[franz1981]

@copilot resolve conflicts

[Copilot]

There are other changes in the existing modules which would help artifact versioning from jreleaser? or it's fine as it is?

The current JReleaser configuration is complete for artifact versioning - no additional changes needed in existing modules. The setup handles:

• Version updates via mvn versions:set in the workflow (updates all module POMs)
• Post-release SNAPSHOT bump for all artifacts (not just core)
• Only core artifact deploys to Maven Central (via artifactIds filter in .mvn/jreleaser.yml)

The configuration is intentionally minimal and leverages JReleaser's defaults where possible.

@copilot resolve conflicts

Conflicts resolved in commit 8df0a33.

Key changes:

• Accepted master's Apache License headers (Netty VirtualThread Scheduler Project format)
• Kept all JReleaser automation files (.github/workflows/release.yml, .mvn/jreleaser.yml, RELEASE.md)
• Updated to master's dependencies (Netty 4.2.9, JUnit 6.0.1, Java 27)
• Merged release profile with master's base POM

POM validation and JReleaser config both pass successfully.

[franz1981]

@copilot rebase over master

[Copilot]

@copilot rebase over master

Branch rebased over master in commits f56a99f through 330b538.

The history is now linear:

• 330b538 Fix YAML formatting - remove trailing spaces
• 2dcbcb5 Add comprehensive release documentation
• 92d7433 Update .gitignore, simplify JReleaser config, and add release documentation
• f56a99f Add Apache License 2.0 and initial JReleaser configuration
• 53cc7db (master) Remove verification documentation file

All JReleaser commits are cleanly rebased on top of master. Validated successfully:
✅ POM validation passes
✅ JReleaser configuration valid
✅ Build successful

Note: The branch has diverged from origin and will need force-push when you next push. The rebased history removes the previous merge commit for a cleaner linear history.

[franz1981]

@copilot provide here the required additional bit I should commit myself in order to make the jreleaser automation to work

[Copilot]

@copilot provide here the required additional bit I should commit myself in order to make the jreleaser automation to work

The JReleaser automation is already complete in the PR. Here's what you need to configure in your repository to make it work:

Required GitHub Secrets

Configure these in Settings → Secrets and variables → Actions:

1. MAVEN_USERNAME - Your Sonatype OSSRH username from https://s01.oss.sonatype.org/
2. MAVEN_PASSWORD - Your Sonatype OSSRH token (preferred) or password
3. GPG_PRIVATE_KEY - Base64-encoded private key:

   gpg --export-secret-keys --armor YOUR_KEY_ID | base64 -w 0

4. GPG_PASSPHRASE - Your GPG key password
5. GPG_PUBLIC_KEY - Your public key:

   gpg --export --armor YOUR_KEY_ID

Optional: GPG Key Generation

If you don't have a GPG key:

gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long  # Get YOUR_KEY_ID
gpg --keyserver keyserver.ubuntu.com --send-keys YOUR_KEY_ID

Post-Merge Steps

1. Set up secrets (as listed above)
2. Verify Sonatype access - Ensure you can publish to io.netty.loom groupId
3. Test release - Use a test version like 0.1.0-RC1 first
4. Trigger workflow - Go to Actions → Release → Run workflow → Enter version

That's it! No additional commits needed - all automation is already in place in the PR.