[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan
|
Hi Scott,
If you take a look at the long-standing items in the Jakarta EE
Ambassadors' Contributor Guide
(https://jakartaee-ambassadors.io/guide-to-contributing-to-jakarta-ee-11/),
the following items are along these lines:
* Modernizing the TCK to take advantage of Maven, JUnit,
Arquillian, etc. It has long been well understood that not doing
this work reduces the velocity of releases of the platform and
older specifications. It also makes the TCK inaccessible to new
contributors. My understanding from Ed is that this is well on the
way to being resolved now. That's why I did not include it in the
Jakarta EE 12 potential plan. Is that not the case? Also,
unfortunately most users and customers would not really care about
this, so it has to be balanced with more marketable changes.
* Making specification TCKs standalone as much as possible and
making more specifications usable on their own in plain Java SE,
without a Jakarta EE runtime. This should include bootstrap APIs
for things like Messaging and Servlet. Indeed this could include a
Java SE bootstrap API for Jakarta EE itself. If there is appetite
for it, consensus around it, and we take it seriously to get it
really done, this could be a very nice marketable item for Jakarta
EE 12. The reason I did not include it is because I assess this to
be an even steeper effort as compared with what I already included
that could make EE 12 get some real market attention.
* Improving testing for Jakarta EE. This could take several
forms. It could simply mean accepting that Arquillian is the
de-facto answer and making sure it is as good as it can be (and I
think currently it is not). It could be moving Arquillian to the
Foundation and improving it there (would Red Hat be open to
this?). It could mean basically standardizing the Arquillian API
into Jakarta EE. It could also mean taking a fresh look at
standardizing a testing API by looking at things like
Testcontainers. Any of these could be pretty marketable for
Jakarta EE 12. The reason I did not include it is that in my
assessment this will take an even longer time to figure out than
what I already listed.
Is any/some of these things what you had in mind or are you
thinking of something else we had not already identified for a
while as a critical gap?
Thanks,
Reza
On 10/27/2024 4:19 AM, Scott Marlow
wrote:
BTW I want to see how far I can push
this forward by October 31, roughly when the
Steering Committee Program Plan needs to be
finalized. If you can at least post something on
those mailing lists by then, I believe it will
make some difference.
Please also consider steps to bring more quality
into our existing releases to help EE applications to get more
out of their code base including making changes in their
applications. Any thoughts on how we could figure out what
that could look like?