User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
Jesse,
Yes, it does appear that Jetty is not a candidate for the
Platform compatibility page. The Google Doc originally indicated
it might be but I think that's been adjusted.
We don't have a compendium of compatible implementations, but we
could well create something for that. That's a great idea.
Originally, there were some ideas about keeping lists of
compatible components on the Spec. pages themselves, but I don't
think we'd actually adopted that yet. Perhaps we should revisit
that.
The process for certification is all open and all the material
needed is available for the price of a mere download -- Get the
TCK, post the passing compatibility results, file an issue with
the appropriate component specification, wait for approval.
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.