I think this is indeed the best way forward. +1
On Thursday, April 11, 2019, Bill Shannon <bill.shannon@xxxxxxxxxx
(Sorry for the cross-posting, but presumably both groups will be interested...)
The Jakarta EE platform javadocs and API jar files are generated from a
subproject of the GlassFish repo.Â A normal build of GlassFish does not build
this subproject, and a normal release of GlassFish does not release this
subproject.Â This subproject collects together all the API artifacts from
all the other API projects, builds them, combines them into the platform
(and profile) API jar files, and generates the combined platform (and profile)
The reason this is part of the GlassFish repo is so that it can share
the configuration of the *versions* of the API artifacts; the actual API
artifacts used by the subproject are defined in the subproject.
I propose moving this subproject to a new repo in the Jakarta EE Platform
project.Â This new Maven project can produce a BOM pom that can be imported
into GlassFish so that the artifact version configuration can still be shared.
Updating GlassFish to use a new version of a component may require updating
the API version in the Jakarta EE platform project and updating the
implementation version in the GlassFish project.Â This will be a minor issue
for components with a clean API/implementation separation, but will be more
of an issue for components that require synchronized updates of both artifacts.
Questions?Â Comments?Â Concerns?
If there are no objections by April 18, I'll start the process to move
this Maven subproject to a jakartaee-api repo in the Jakarta EE Platform
glassfish-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit