User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
Chris
That's great news. Sorry to have introduced this distraction. I
don't intend this to diminish the work you are doing. I look
forward to the day Jetty and more products are using, and passing
the TCKs.
-- Ed
On 12/18/2020 12:01 PM, Chris Walker
wrote:
My original thought with this was to have an open
space where projects and committers could share their own
experiences and successes with bringing their work to EE9,
whether big or small (or even non-technical). This whole thing
has been a rather large community effort and I think it is good
to have an outlet where folks can showcase the work they've
done.
There's been a lot of talk on the thread about the TCK
(which is great, I think more people taking part in that would
be good) and other qualifiers, but I am not entirely sure it
is warranted. At Jetty we are still working on our own TCK
adoption, and I am sure others have a ways to go as well.
To respond to the note I entered in the
Google Doc., it sounds like Netty isn't
actually a candidate for the Jakarta EE
compatibility page since it doesn't
implement the platform, or web profile.
That's a bummer.
A bit off-topic for the thread but..
There are enough open source projects
implementing aspects of JakartaEE, if the
compatibility page is not appropriate for
something like Jetty or Netty then we should
have another page for all the rest of us
since we are all participating in Jakarta in
some way, shape or form. If Jetty usage
alone is any indication there is a very
large community of users of JakartaEE
components out there that have no need or
interest in the larger stacks. Maybe such a
page exists but I am not aware of it and I
don't know that mentions on specific
specifications is an appropriate location
since many projects implement multiple
specifications.
cheers,
Jesse
The TCKs listed by Chris earlier (JSP,
Servlet,
and WebSocket)
are each available as separate TCKs.
Refactoring the TCKs is only an issue
for production of the TCKs, not for
vendors who wish to certify
compatibility. Mike, you are absolutely
correct, no agreement needs to be
executed. I would submit that the
certification process and filing a
GitHub certification issue for each API
ought to be completed, if we are going
to stick with the process we have
outlined.
Personally, I would like to see more
adoption of this process so that the
community and vendors start to recognize
the TCKs as a benefit for users across
the board.
-- Ed
On 12/18/2020 8:56 AM, Mike
Milinkovich wrote:
On 2020-12-18 11:43 a.m., Ed Bratt
wrote:
Ideally, the TCKs would be used to
demonstrate compatibility, even with
component Specs. Now that they are
all open-source and available to any
project, we should encourage folks
to use them and show the community
their value.
Yes. Exactly. And as a reminder, one
of the biggest differences between
Jakarta EE and Java EE is that under
the Eclipse
Foundation TCK License, you can
make bona fide claims of
compatibility with individual specs
and without signing any agreements
with anyone.
Refactoring "the TCK" into "the
specification TCKs" still needs to be
done. It will be pretty cool when it
is.
On 12/18/2020 8:02 AM, Werner
Keil wrote:
I added that
remark (Servlet and a few other
specs) because otherwise „Fully
Compatible“ may sound a bit too
much like the Full Profile.