I've answered that same question twice now. I'm not sure what else
to say.
Have you read the TCK Users Guide, in particular Chapter 2 where it
lists all the compatibility rules?
(Note that none of this is about "Jakarta EE". This is all about
the Jakarta RESTful Web Services spec and TCK. Often "Jakarta EE"
is just used as a shorthand for the rules, processes, etc. that
apply to all these specs.)
Markus KARG wrote on 9/15/19 10:39 PM:
Bill,
there
IS an unanswered question, I am AM really confused.
The
question is: How can an API JAR be compliant to Jakarta EE?
How is the compliance of an API JAR (not of a product) to
Jakarta EE be defined and tests?
I
do not claim that the API jar is not compliant. I want to
know exactly that, nothing else. To be compliant, there must
be a rule to be checked. What is that particular rule?
Please answer *that* to make me understand that particular
detail of Jan's mail.
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Montag, 16. September 2019 00:13
An: jaxrs developer discussions; Markus KARG
Betreff: Re: [jaxrs-dev] Jakarta RESTful Web
Services API 2.1.6 is available in maven central
Markus, I
don't know what answer you want.
Would you be happy if I said the TCK does not verify the API
jar file at all?
I don't believe that's true, but that seems to be the answer
you're looking for.
I believe the API jar file is verified indirectly by the TCK.
Is it possible to construct a product composed of an API jar
file and an implementation jar file, that passes the TCK, and
yet the API jar file alone does not correctly provide the
required API? Yes, of course it is. Such an error might not
be detected by the TCK, but that API jar file would violate
the rules in the TCK. Not everything that's required is
tested.
Markus, as far as I can tell, you're not confused by any of
this. There isn't a question you're asking that hasn't been
answered. You're just being argumentative because you don't
like Jan's answer that the API jar file is compliant, but you
haven't explained in what way you believe it is not
compliant. It's clear that it is not a compliant Product, but
it is a compliant API Definition Product.
Markus KARG wrote on 9/15/19 10:24 AM:
Arjan,
yes
that is clear. But it does not answer my question.
-Markus
Hi,
You can’t check the product without
having the API in place.
For most APIs I tested, this simply
meant deleting the API jar from GlassFish’s modules
folder and then copying the new API jar to it.
If you subsequently run the TCK against
the product, it will use the updated API jar as part of
that run.
You can’t currently run the TCK against
just the API jar.
Kind regards,
On Sunday, September 15, 2019, Markus KARG <markus@xxxxxxxxxxxxxxx>
wrote:
We
go in circles… ;-(
My
original claim actually was that the TCK does NOT
check the API JAR but only the product. Then Jan
Supol said he pushed an API JAR (not a product) to
Maven that is compliant to Jakarta EE 8. I asked how
the API JAR's compliance (not the product's) is
defined. I was told, this was done by the TCK. I
asked how the TCK does that. And now you tell me,
the TCK DOES NOT check the API, but it checks the
product.
So
back to my original question: Jan, what do you mean
with "the API JAR is compliant to Jakarta EE 8"? How
is the compliance OF AN API JAR (not of a product)
defined and verified? Following Bill's recent answer
it is NOT verified by the TCK.
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Sonntag, 15. September 2019
05:06
An: jaxrs developer discussions; Markus
KARG
Betreff: Re: [jaxrs-dev] Jakarta RESTful
Web Services API 2.1.6 is available in maven
central
No,
it verifies that the classes and methods exist in the
product.
You configure the TCK to know about the jar file(s)
that make up the product.
You should definitely read the TCK Users Guide for the
Jakarta RESTful Web Services TCK. It will answer some
of your questions, but you may also discover that it
needs a lot of work.
There's some things that are allowed or restricted by
the TCK rules (in the TCK Users Guide) but that aren't
actually tested by the TCK. The contents of a
separately distributed API jar file is one of those.
Markus
KARG wrote on 9/14/19 9:12 AM:
So
the TCK really does verify that the classes and
methods exists in the *API* JAR?
Is
that mandatory for TCKs in general or is this up
to all subprojects to decide (so it could get
moved from the TCK to the subproject's unit
tests)?
-Markus
Hi,
The
signature test is a well known part of the TCK
that essentially tests whether all the classes and
methods are exactly there, without any method
missing, and without any class or method or
annotation etc being added, or any parameter being
changed, even if it’s in a seemingly binary
compatible way.
On Saturday, September 14, 2019, Markus KARG <markus@xxxxxxxxxxxxxxx>
wrote:
What
I do not understand in the following part of your
explanation:
"An API jar file in combination with an
implementation can pass the TCK."
This implies that there is something in the TCK
that does not check the implementation, but in
fact does check the API JAR. Can you give an
example what part of Jakarta REST's TCK actually
does test the API jar instead of testing the
implementation? You mention "signature tests".
What is the intention of that? I am asking because
next step at Jakarta REST certainly will be the
adoption of our TCK into our repo, so we need to
learn the not-so-obvious parts of that.
Thanks
-Markus
-----Ursprüngliche Nachricht-----
Von: Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Montag, 9. September 2019 23:36
An: jaxrs developer discussions; Markus KARG
Betreff: Re: [jaxrs-dev] Jakarta RESTful Web
Services API 2.1.6 is available in maven central
I thought it did. Maybe you'd like to restate
your question?
Perhaps there's some subtlety that I'm missing.
To be clear, an API jar file *alone* can not pass
the TCK.
An API jar file in combination with an
implementation can pass the TCK.
Given the intended use of an API jar file, it
should pass the signature
tests in the TCK, which can be shown by running
the full TCK against
the API jar file plus an implementation.
Markus KARG wrote on 9/7/19 12:52 AM:
> I know that, but it does not answer my
original question to Jan.
> -Markus
>
> -----Ursprüngliche Nachricht-----
> Von: Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
> Gesendet: Freitag, 6. September 2019 20:20
> An: jaxrs developer discussions; Markus KARG
> Betreff: Re: [jaxrs-dev] Jakarta RESTful Web
Services API 2.1.6 is available in maven central
>
> Presumably the TCK was run with the new API
jar file and the existing
> implementation. That combination would be
compatible with the spec
> requirements.
>
> The API jar file alone meets the spec
requirements in the sense that it
> provides valid signatures for the APIs. API
jar files are only intended
> for use to compile against (although they may
be useful for other things)
> so only the API signatures matter.
>
>
> Markus KARG wrote on 9/6/19 9:30 AM:
>> How can an API pass its own TCK? Only an
implementation can pass a TCK.
>> -Markus
>>
>> -----Ursprüngliche Nachricht-----
>> Von: jaxrs-dev-bounces@xxxxxxxxxxx
[mailto:jaxrs-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Jan Supol
>> Gesendet: Freitag, 6. September 2019
18:14
>> An: jaxrs-dev@xxxxxxxxxxx
>> Betreff: Re: [jaxrs-dev] Jakarta RESTful
Web Services API 2.1.6 is available in maven
central
>>
>> Hi Markus,
>>
>> Well, it passed the Jakarta RESTful Web
Services TCK 2.1 :)
>>
>> -- Jan
>>
>> On 06.09.2019 10:26, Markus KARG wrote:
>>> Thanks, Jan!
>>>
>>> But actually I am wondering what
"Jakarta EE 8 COMPLIANT" means? How is that
>>> COMPLIANCE defined?
>>>
>>> -Markus
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: jaxrs-dev-bounces@xxxxxxxxxxx
[mailto:jaxrs-dev-bounces@xxxxxxxxxxx]
Im
>>> Auftrag von Jan Supol
>>> Gesendet: Donnerstag, 5. September
2019 22:08
>>> An: jaxrs-dev@xxxxxxxxxxx
>>> Betreff: [jaxrs-dev] Jakarta RESTful
Web Services API 2.1.6 is available in
>>> maven central
>>>
>>> Dear Jakarta RESTful Web Services
Community,
>>>
>>> The Jakarta EE 8 compliant Jakarta
RESTful Web Services API 2.1.6 is
>>> available in maven central [1].
>>>
>>> Thank you,
>>>
>>> Jan
>>>
>>> [1]
>>> https://search.maven.org/artifact/jakarta.ws.rs/jakarta.ws.rs-api/2.1.6/bund
>>> le
>>>
>>>
_______________________________________________
>>> jaxrs-dev mailing list
>>> jaxrs-dev@xxxxxxxxxxx
>>> To change your delivery options,
retrieve your password, or unsubscribe from
>>> this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jaxrs-dev
>>>
>>>
_______________________________________________
>>> jaxrs-dev mailing list
>>> jaxrs-dev@xxxxxxxxxxx
>>> To change your delivery options,
retrieve your password, or unsubscribe from this
list, visit
>>> https://www.eclipse.org/mailman/listinfo/jaxrs-dev
>>
_______________________________________________
>> jaxrs-dev mailing list
>> jaxrs-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve
your password, or unsubscribe from this list,
visit
>> https://www.eclipse.org/mailman/listinfo/jaxrs-dev
>>
>>
_______________________________________________
>> jaxrs-dev mailing list
>> jaxrs-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve
your password, or unsubscribe from this list,
visit
>> https://www.eclipse.org/mailman/listinfo/jaxrs-dev
>>
>
>
_______________________________________________
> jaxrs-dev mailing list
> jaxrs-dev@xxxxxxxxxxx
> To change your delivery options, retrieve
your password, or unsubscribe from this list,
visit
> https://www.eclipse.org/mailman/listinfo/jaxrs-dev
>
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
|
