Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

How to release first versions of EE4J components

This is a HOWTO guide for releasing the first Eclipse version of projects after transferring them from Java EE.

General Workflow

1. Release a project to OSSRH staging repository. Instructions are below.

2. Submit a project for release review. Instructions are below.

3. After passing all CTS/TCK tests, all components will be released to Maven Central.

Releasing a Maven Artifact

1. Create CI/CD release pipeline. GitHub tasks are created for each repository. Releasing Maven artifacts from EE4J projects must be done using CI/CD pipelines (Maven Nexus plugin). Each EE4J project has OSSRH account associated with it. Maven Nexus plugin must be configured to use the project's OSSRH account. Use New Infra Release Job article for reference.

2. Make sure that Eclipse project account has write access on OSSRH to Maven groups it's releasing to. In case of the first release it doesn't. Create a bug in BugZilla listing artifacts you want to deploy and let Eclipse webmaster handle it. See this bug for reference.

3. Release must not introduce any API changes.

4. If components depend on other EE4J components, make sure that the latest deployed to OSSRH staging repository versions are used. Use GlassFish 5.1 Release Tracker page to find out components versions to use.

5. EE4J_8 branch must be used for the first Jakarta EE release. The released version should be the project's next version after the Java EE release. For example, it should be version 1.0.1 if the last version released by Oracle is 1.0.

6. Release to OSSRH staging repository. GitHub tasks for API and implementation projects. Additional instructions can be found here.

7. Integrate to GlassFish by submitting a PR to GlassFish repository on GitHub.

Release Review

1. Make sure project contains NOTICE, LICENSE and CONTRIBUTING files in the repository root. Use Legal Document Generator to generate these files if needed.

2. Send an email to project’s mailing list to inform committers about this release and make sure that there are no objections. This email should contain general information about the release and a version number.

3. Create a release record for the project using Create New Release command on specific project page (see Eclipse Handbook for details, JSONP release for an example). Make sure that you logged to Eclipse, otherwise you won't see these options. Be sure to select a release date at least two weeks in the future, to allow for IP review and community review.

4. Schedule a review for the release by clicking Schedule a Review for this release link that appears at the top of the release record page.

5. Send notification to by clicking The Eclipse Management Organization link that appears at the top of the release record page after scheduling a review.

6. Submit the IP Log for review by the IP Team using Generate IP Log tool on a specific project page (see IP Log Generator for details). Make sure that you logged to Eclipse, otherwise you won't see these options. The IP review should be requested to be complete one week before the release date.

7. Obtain PMC approval by sending request to, feel free to use following template:

Dear PMC,
I'd like to get approval for the <PROJECT_NAME> <VERSION> release.
The release review docs are available at<project_id>/releases/<version>/review


8. At some point during the process the tracking bug will be created by the Eclipse Foundation. Use to track release review status and provide all information requested by the Eclipse.

Back to the top