Hi All,
why not think about standardizing this implementation present in wildfly? like this:
Regards
Angelo Rubini
Community members,
I am writing this email to your community now
that the April 15 deadline is fast approaching.
As of now, a release plan for a next release of
your component has not been created or an
indication put in the opened issue in my
original email to state that you do not plan a
release that could be considered for Jakarta EE
12.
It was brought to my attention that people may
not realize what is being asked to be done when
creating a release plan. There is information
in the issue provided on the how, but the main
point of having a release plan is that we are
looking to know that you are planning to do
something and whether you are looking at doing a
minor release or a major release depending on
the types of changes. What is in the release
plan that you create can change over time, but
at least there is an indication that you are
working to make a new release even if you don't
know what all will be in it yet. We are not
asking for all issues to be created and code,
tests, implementation or specs to be updated in
order to make a release plan. If you look at
the release plans created so far, you will find
that some of them are quite vague. They are
just saying yes we plan on doing a new version
of the component. A release plan also gives an
indication to those not in the Jakarta community
that work is happening in the specification that
they can look forward to and possibly suggest
changes. If you need help with making your
release plan, please reach out to Ed or me on
slack or email.
Enterprise Beans was identified as a component
that requires a new release in order to remove
Java SecurityManager language from the
specification
at this location.
If there are no other things to be added to a
release plan for Enterprise Beans, that is ok.
It can just be a very minor release to update
the specification to remove SecurityManager
references.
Thanks,
Jared Anderson
Jakarta EE 12 Release Co-coordinator
Community members,
Executive Summary
a. If you don't plan to have a new version
for your specification in EE 12, just close the
issue.
b. If you plan to have a new version, use
the issue to create a release plan by April 15,
2025.
2. See
this dashboard where the component release
plan issues are tracked.
Details
On Monday I opened
issue #153 in your repository to request
your community to consider a new release of your
component for Jakarta EE 12 by creating a new
release plan. The issue contains a lot of
details that explain what to do to create a
release plan. You can use the issue to
document initial thoughts and reference other
issues in your repository as you work out what
you want to include in a release plan.
A dashboard in GitHub was created to track the
status of the release plan issues. The
dashboard, located
here, contains both a Board and Table view
of the release plan issues. What is being asked
of each community is to decide on if you plan to
have a new release to be considered for EE 12 or
not. If not, closing the issue will move it to
the final column on the dashboard. If you are
planning to have a new version of your component
for EE 12, please follow the instructions in the
issue by April 15, 2025 in order to get your
issue moved to the second column for your mentor
to look at the issue and get it ready for a plan
ballot. You will see that your issue in the
board includes the name of the mentor that was
assigned to your component in EE 11.
Thanks,
Jared Anderson and Ed Burns
Jakarta EE 12 Release Co-coordinators
