Re: [jakartaee-platform-dev] [External] : Re: [jakarta.ee-spec] What are our optionsfor Jakarta EE 10 going to ballot without GlassFish passing the Concurrency3.0 TCK?
Thread-topic: Re: [jakartaee-platform-dev] [External] : Re: [jakarta.ee-spec] What are our optionsfor Jakarta EE 10 going to ballot without GlassFish passing the Concurrency3.0 TCK?
I know it puts some folks in an odd position but one should perhaps inevitably inquire - is it so unreasonable to ask that the relevant Payara features be contributed back to GlassFish?
That way, we could have a more reliable, developer friendly release and have two reasonable options in both GlassFish and Payara sooner rather than later? What’s the significant hurdle? Perhaps the current GlassFish developers could even help do the code merge back with some level of agreement and cooperation from Payara?
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> Sent: Wednesday, June 8, 2022 6:14 PM To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx> Subject: Re: [jakartaee-platform-dev] [External] : Re: [jakarta.ee-spec] What are our optionsfor Jakarta EE 10 going to ballot without GlassFish passing the Concurrency3.0 TCK?
I am with Ed on this. We discussed the same thing in MicroProfile releases in the past. The conclusion was that we really need to demonstrate the technologies work together with one single runtime. With joint runtimes collectively passing the whole profile does not prove the whole integration working. Some of the specs might have conflicting features and they do not work together. Since we are releasing profiles as a whole piece instead of individual specs, the reasonable requirement is that showing the community it can be implemented by one runtime. if we can't really demonstrate that, how can we tell our customers that you can use all things from web profile/platform release?
I think a reasonable resolution for this is to delay the release date rather than taking a short cut.
My concern is, we don't know if there is something conflicting
within the specification requirements. As the respective component
specifications are moved out of the Platform TCK project, this
project will cover less and less of the component technologies.
This problem will continue to grow.
The requirement that a product meet all the requirements listed
in that specification ensures that at least one product is able to
meet all the specifications. I know that vendors have from time to
time used that knowledge to validate their implementations.
Personally, I think that goal this is more important to the
specification on the whole, than a particular date. I would
recommend we wait until we can sort out the issue with concurrency
(I believe there are a few other straggling issues as well but
Currency seems to be the focus of this thread).
Enterprise Java has always been a tight collaboration between
implementation teams and specification writers. I think that is
one of it's key values and has set it apart from many other,
similar efforts.
-- Ed
On 6/8/2022 9:17 AM, Reza Rahman wrote:
I think it's important to bear in mind there are plenty of
successful open standards/specifications that do not have any
guaranteed implementations at all when they ship.
It's fine to be pragmatic, relax the rules a bit at least
temporarily and see how it all plays out. I believe the most
important thing is to get some kind of regular innovation
cadence for Jakarta EE. There seems to be plenty of good, solid
stuff in the release.
On 6/8/22 11:59 AM, Scott Stark
wrote:
Yes, eventually there will be fully compliant
implementations. The question is when? There is no one vendor
whose produce roadmap is aligned with Jakarta EE because it is
a front running development that they have to catch up too. A
pseudo de facto standard is requiring other to commit
resources to try to finalize the specification. This is really
not a viable model given the current structure of the project.
The current situation is either use a composite CCR that
validates no single implementation, but provides some validation
of the specification, or wait for an implementation to provide a
CCR. The problem with the later is that we are currently
requiring at least one implementation to pass everything TCK
including optional aspects. We need to stop pushing the rock up
the hill and move to a more flexible development model.
There may be a „de facto RI“
but there is no real RI anymore, so do other
implementations like Wildfly, Payara or TomEE
expect to pass all these TCKs in the near future?
This
makes sense to me as we are all effectively
working towards getting our implementations
compatible.
Currently
we have had a de-facto RI since the beginning
with GlassFish. Whereby GlassFish is required to
pass all the TCKs in order to release a platform
specification. This leads GlassFish to be always
on the critical path for a platform release.
Having
the totality of the TCK testing covered by a
range of compatible implementations will also
remove the requirement to have a single
Compatible Implementation project team on the
critical path for the platform release.
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx>
On Behalf Of Scott Stark Sent: 08 June 2022 16:08 To: jakartaee-platform developer
discussions <jakartaee-platform-dev@xxxxxxxxxxx> Cc: Jakarta specification discussions
<jakarta.ee-spec@xxxxxxxxxxx> Subject: Re: [jakarta.ee-spec]
[jakartaee-platform-dev] What are our
options for Jakarta EE 10 going to ballot
without GlassFish passing the Concurrency
3.0 TCK?
Right, they would have to ask
their favorite project when they will be fully
certified. Effectively there would need to be
a ratification type of CCR that did not convey
full compliance, but that is what reflects the
reality of doing away with a single reference
implementation in favor of multiple compatible
implementation. The downside being what you
have referred to.
Honestly this would
be OK in practice. The only
downside is that developers
would be a bit confused about
the fact that while there is a
platform or profile release,
there wouldn’t actually be
anything that implements the
platform or profile just yet.
The main issue here
is what is required for the
platform spec and profiles in
terms of the ratifying CCRs. We
have standalone TCKs being
ratified that are not using
GlassFish. It would greatly
simplify producing the EE releases
if profiles/platform specs could
be ratified via a union of
incomplete CCRs.
A single CCR that
lists the compatible
implementation for the
profile/platform in question, and
then the compatible implementation
for each standalone TCK is what
would be ideal. If we could to
that, we would have a CCR today.
I'm CCing the
platform team as is probably also
is up to them as to what they
would be willing to accept.
The ongoing
discussion [1][2] about
GlassFish 7 implementing the
remaining aspects of
Concurrency 3.0 is about who
will make the remaining
GlassFish changes. The Payara team is
considering making the
needed GlassFish changes
which is great but blocking
on Payara to make those
changes may impact the EE 10
schedule which is a valid
concern.
What are our options for
going to EE 10 ballot
without GlassFish passing
the Concurrency 3.0 TCK but
instead some other
implementation passing the
Concurrency 3.0 TCK? The
other implementation release
would likely pass other EE
10 TCKs as well but not all
of the TCKs.
Can we go to ballot with
EE 10 with GlassFish passing
all of the other TCKs (not
that we are there yet but
are working hard on it) and
the other implementation
release passing the
Concurrency 3.0 TCK?